Notes |
|
(0004398)
|
domdorn
|
01-28-10 14:51
|
|
This also happens when simply restarting the application by touching .reload in /
This is a serious problem, as it eats up the whole available disk space in few minutes.
Priority should be raised to major. |
|
|
(0004470)
|
michitopf
|
03-19-10 11:30
|
|
I'm using Tomcat 6 and am facing the same problem. The growing log file consumes the whole disk space and the server hangs. This bug is dramatic. Please raise priority. |
|
|
(0004476)
|
flushot
|
03-22-10 08:16
|
|
I'm able to reproduce this on Tomcat 6.0.18 after letting the container run for a little while. |
|
|
(0004523)
|
domdorn
|
04-12-10 08:59
|
|
This is even more a problem when people try to add quercus to the default-web.xml of their servlet container to "add php support", meaning it servlet will be loaded with every web-app and the bug be triggered by the first webapp that needs to be reloaded/redeployed, effectively forcing an app-server restart when changing one app. |
|
|
(0004524)
|
garry donnelly
|
04-12-10 09:37
|
|
Can't add anything new to this except to say this should probably be a higher priority as it pretty much a killer for any production site. |
|
|
(0004528)
|
domdorn
|
04-13-10 05:57
|
|
hmm... why is the AlarmCoordinatorThread still active, after undeploying the app? Shouldn't that one be stopped and removed from memory when undeploying the app? |
|
|
(0004529)
|
domdorn
|
04-13-10 06:58
|
|
Ok, I've been digging through the code, thats what I found:
As soon as the quercus.jar is loaded, the static { } code of Alarm.java is executed, creating two threads: on AlarmThread and one CoordinatorThread.
Both run() { } methods are programmed in a way, that they _never_ complete, because they have a while(true){ try{ ... } catch( Throwable e ) { } } block, meaning they will keep running, even when undeploying the app.
I've adjusted some classes to fix this issue.
I've created a branch in my github repo for this:
http://github.com/domdorn/resin/tree/0003711-fix [^]
The fix is quite small.. it basically allows to cleanly shutdown the AlarmThread and the CoordinatorThread by setting a status variable that gets queried in the run() method of those threads. If the status is false, the loop ends and therefor, also the thread ends.
It would be nice if some of you could take a look at this patch. If necessary, I'm transferring all the copyrights of this little patch to the resin/quercus team, so this issue finally gets fixed!
|
|
|
(0004530)
|
domdorn
|
04-13-10 09:53
|
|
Actually a better place for invoking the destruction of the AlarmThread and the CoordinatorThread would be a ServletContextListener, but I'm not sure if the Caucho guys want that. |
|
|
(0004546)
|
nam
|
04-28-10 13:04
|
|
Fixed for 4.0.7.
On Tomcat, Quercus Open Source no longer uses Resin's ThreadPool and AlarmThread. |
|