Skip to main content

Diagnosing web application shutdown issues

2 replies [Last post]
scotey
Offline
Joined: 2005-12-21
Points: 0

I have a RESTFul application that is deployed on Glassfish 4 that does not properly shut down. An exception is thrown when the application is undeployed and it shows on the Glassfish applications panel as a stack trace. And though it appears upon refresh that the application is no longer deployed, subsequent redeploys fail because the old application has left behind some garbage that is not gone until Glassfish is stopped and restarted.

I could paste the stack trace, and maybe I will if that is what the folks want to see here. My feeling is that after the web container shuts down, there are still threads running that haven't cleaned up properly that may be trying to access resources that are no longer available. I've seen this before with other web containers such as Tomcat, and I've installed clean up filters that forcibly clean up connection pools and ThreadLocal variables. It's ugly and brute-force, and in this latest case, not working to allow a proper shutdown. As a result, I cannot redeploy through any automatic mechanism built-in to, for instance, the maven deploy plugin. It's a manual process until I can work this out.

So, I'd like some advice on how to debug and find this issue. Problem is, once the web container has been shut down, I lose my remote debug connection. Ideally I could issue what by all accounts seems like a web container shutdown to cause my web application to go through all the motions of a shutdown to see what the issue is. Beyond that, I need help with a strategy. I think the issue is around either EHCache or JPA/Eclipselink.

None of this is code I wrote--it's inherited so a large part of it is unknown to me as of yet.

If you have suggestions, I would greatly appreciate them.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
whartung
Offline
Joined: 2003-06-13
Points: 0

At a minimum you can undeploy your application from asadmin or the console, and the debugger will still be connected, since it's tied to the container, not your application. By the same notion, you can attach the debugger to the server, set breakpoints in your web apps initialization code, and then deploy the app and the debugger should catch the breakpoints in the your newly started app.

Leaking Threads and ThreadLocals is a common thing that causes this kind of thing.

scotey
Offline
Joined: 2005-12-21
Points: 0

I've definitely debugged the startup of the web application, and I believe I've tried what you are suggesting before. I'll run through the process once and see if your suggestion works.

Thanks for the reply.