0003711: NullPointerException in Alarm (after Glassfish redeploy)

(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
edited on: 04-13-10 07:12

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.

Issue History
Date Modified	Username	Field	Change
10-15-09 11:10	nam	New Issue
10-15-09 11:25	nam	Summary	NullPointerException in Alarm => NullPointerException in Alarm (after Glassfish redeploy)
01-28-10 14:51	domdorn	Note Added: 0004398
01-28-10 14:51	domdorn	Issue Monitored: domdorn
03-19-10 11:30	michitopf	Note Added: 0004470
03-22-10 08:13	flushot	Issue Monitored: flushot
03-22-10 08:16	flushot	Note Added: 0004476
04-12-10 08:59	domdorn	Note Added: 0004523
04-12-10 09:26	garry donnelly	Issue Monitored: garry donnelly
04-12-10 09:37	garry donnelly	Note Added: 0004524
04-13-10 05:57	domdorn	Note Added: 0004528
04-13-10 06:58	domdorn	Note Added: 0004529
04-13-10 07:12	domdorn	Note Edited: 0004529
04-13-10 09:53	domdorn	Note Added: 0004530
04-28-10 13:03	nam	Status	new => assigned
04-28-10 13:03	nam	Assigned To	=> nam
04-28-10 13:04	nam	Status	assigned => closed
04-28-10 13:04	nam	Note Added: 0004546
04-28-10 13:04	nam	Resolution	open => fixed

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 edited on: 04-13-10 07:12	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.

Relationships