• Post Reply Bookmark Topic Watch Topic
  • New Topic

How to identify threads that prevent tomcat app from undeploying

 
Jeff Black
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have a simple webapp that runs in Windows, Tomcat 6.x and uses embedded derby. Undeploy does not complete cleanly leaving behind a WEB-INF/lib/derby.jar file that windows says is still in use by another process.

We are having a hard time tracking down which thread is causing this problem. We don't explicitly start any threads, so not sure where the "daemon" property would be set to properly terminate all threads. We have tried watching JMX console when the undeploy happens, but nothing in the thread list looks suspect.

So the question is, what is the best way to track down a thread that is not being a good citizen? If we knew which thread it was, we could properly manage it, but we're at a loss to even identify it.

The only clue besides the leftover derby jar file is that after the undeploy, we CTRL-C the tomcat console and get this stack trace:

INFO: Undeploying context [/psps]
java.util.logging.ErrorManager: 1
java.lang.NullPointerException
at org.apache.juli.FileHandler.publish(FileHandler.java:137)
at java.util.logging.Logger.log(Logger.java:452)
at java.util.logging.Logger.doLog(Logger.java:474)
at java.util.logging.Logger.logp(Logger.java:590)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:165)
at org.apache.juli.logging.DirectJDKLog.info(DirectJDKLog.java:115)
at org.apache.coyote.http11.Http11Protocol.pause(Http11Protocol.java:220)
at org.apache.catalina.connector.Connector.pause(Connector.java:1073)
at org.apache.catalina.core.StandardService.stop(StandardService.java:563)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:628)
at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:671)
 
Jeff Black
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, meant to post this to "Threads and Synchronization". Should I re-post there or can someone move it?
 
Pho Tek
Ranch Hand
Posts: 782
Chrome Python Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're on unix/linux, just run the following to get a thread dump.

kill -SIGQUIT <pid.of.tomcat>
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just a wild guess, but maybe Derby needs to be explicitly shut down? I could imagine it starting various threads that need to be properly terminated.
 
Jeff Black
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am fairly confident we are shutting down derby properly based on the derby website instructions. We have several other wars that do the same thing, so now problems there using the same shutdown steps.

Others in our office have tried this under linux and no problems there, so it is a windows specific issue/symptom.

Also, I wanted to report that the problem has disappeared after an upgrade from tomcat 6.0.16 to 6.0.18. We can now undeploy cleanly. This may or may not be the real solution to our problem as maybe this new version is more forceful about terminating webapp threads, but, I would think as the app developers, we should make sure we understand what our threads are doing and should explicitly make sure they are terminate cleanly.

However, I am still very curious about the original question of, how does one track down a misbehaving thread, whether it be a webapp or otherwise.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!