Mantis - Quercus
Viewing Issue Advanced Details
3711 minor always 10-15-09 11:10 04-28-10 13:04
nam  
nam  
normal  
closed  
fixed  
none    
none  
0003711: NullPointerException in Alarm (after Glassfish redeploy)
(rep by ashamash)

Using Quercus 4.0.1, I'm consistently getting the following exception, approximately 30 seconds after undeploying, redeploying, and accessing the application in Glassfish. This does not happen after the initial deploy, only after redeploy.

Once the exception happens, it then happens in a very tight loop, making the app server unusable, forcing a restart (see timestamps from server log file below). This effectively means a restart on every deploy.

The same application did not have any issues with Quercus 3.1.6:

[#|2009-10-15T10:47:59.649-0400|WARNING|sun-appserver2.1|com.caucho.util.Alarm|_ThreadID=17;_T hreadName=alarm-coordinator;_RequestID=7364023f-c2ef-49ff-b191-a77c66ce3dd1;|java.lang.NullPointerException
java.lang.NullPointerException
at com.caucho.util.Alarm.extractAlarm(Alarm.java:432)
at com.caucho.util.Alarm$CoordinatorThread.run(Alarm. java:704)
|#]

[#|2009-10-15T10:47:59.654-0400|WARNING|sun-appserver2.1|com.caucho.util.Alarm|_ThreadID=17;_T hreadName=alarm-coordinator;_RequestID=7364023f-c2ef-49ff-b191-a77c66ce3dd1;|java.lang.NullPointerException
java.lang.NullPointerException
at com.caucho.util.Alarm.extractAlarm(Alarm.java:432)
at com.caucho.util.Alarm$CoordinatorThread.run(Alarm. java:704)
|#]

[#|2009-10-15T10:47:59.657-0400|WARNING|sun-appserver2.1|com.caucho.util.Alarm|_ThreadID=17;_T hreadName=alarm-coordinator;_RequestID=7364023f-c2ef-49ff-b191-a77c66ce3dd1;|java.lang.NullPointerException
java.lang.NullPointerException
at com.caucho.util.Alarm.extractAlarm(Alarm.java:432)
at com.caucho.util.Alarm$CoordinatorThread.run(Alarm. java:704)
|#]

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.