今天早上更新了一下应用,shutdown.sh,再start.sh,然后发现所有的应用都无法访问了,就是没反应,也不回应拒绝访问等错误信息,就僵死在那里,检查了半天才发现在shtdown.sh后,仍然有进程在监听8080端口,导致重新启动tomcat时无法绑定端口而失败,继续google发现原来很多情况都能造成tomcat无法关闭线程(最典型的就是用了ssh框架)的情况,手动杀线程后搞定问题,但是这个问题实在太不爽了,我的tomcat是需要经常重启来更新测试应用的,这经常僵尸太不爽了,求正确的安全重启tomcat方法

解决方案 »

  1.   

    会有线程占用之前端口.  一般servlet  timer写的代码会比较容易出现.解决方法是  :ps -aux | grep tomcat目录名称会有qiunet    8476  0.7 11.4 584396 237248 pts/0   Sl   12:28   0:47 /usr/bin/java -Djava.util.logging.config.file=/usr/local/app/tools/fish_test/conf/logging.properties -Djava.awt.headless=true -Xms128M -Xmx256M -server -XX:PermSize=64M -XX:MaxPermSize=128M -XX:+PrintGCDetails -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/app/tools/f_test/endorsed -classpath /usr/local/app/tools/f_test/bin/bootstrap.jar -Dcatalina.base=/usr/local/app/tools/f_test -Dcatalina.home=/usr/local/app/tools/f_test -Djava.io.tmpdir=/usr/local/app/tools/f_test/temp org.apache.catalina.startup.Bootstrap start第二个(8476)是pid  然后
    kill  -9  pid .再重启就行了
      

  2.   

    sorry.没看全. 代码方面没有经历过.不知道怎么正.  提供个思路.你可以写个脚本.执行kill这步.就行了.  shell脚本完全可以shutdowm.sh 然后 kill pid ,然后重启.
      

  3.   

    楼上2个...强关不解决核心问题...
    关不掉tomcat,你得首先查代码
    是不是有线程卡死了
    是不是有socket卡死了
    等等,关不掉不是tomcat的错,是你开发人员的错!
      

  4.   

    3楼说的有道理,我也碰到这种情况。代码里面起后台线程的情况比较多,我有点懒,不大愿意花工夫去找原因,基本上就是程序里有线程占用资源,退不掉,就导致tomcat退不出了。
    不过个人觉得tomcat本身的处理也是有问题的,shutdown失败不会有任何提示,再startup还会成功,我有时候就是猛然发现tomcat运行了一批实例.jetty在这方面做得比较好,在启动或者停止脚本里面加一个循环,用PS来看进程是不是还在,其实也不是很麻烦的事,tomcat就没处理这种情况。
      

  5.   


    一个很简单的用ssh实现的bs框架,在前台页面对一个数据库实现crud而已,完全是照搬教科书,这样的程序到底有什么问题呢?而且这个情况不是每次都出现的,就是偶尔才有
      

  6.   

    我也是LINUX上面关很慢,会出现假死的情况,实际上那个应用文件夹不知道被那个进程占用呢!·