View Full Version : Moodle on GlassFish fills up logs with NPE

12-22-2009, 02:19 PM
I am running Moodle on GlassFish with Quercus, and my logs fill up incredibly quickly with entries like the following:

[#|2009-12-22T07:16:40.677-0800|WARNING|glassfishv3.0|com.caucho.util.Alarm|_ ThreadID=33;_ThreadName=Thread-1;|java.lang.NullPointerException
at com.caucho.util.Alarm.extractAlarm(Alarm.java:479)
at com.caucho.util.Alarm$CoordinatorThread.run(Alarm. java:746)

How can I stop that?



12-22-2009, 05:02 PM
Can you send the full stack trace for that NPE?


12-23-2009, 11:27 PM
this does not only happen with moodle, but also with some of my own scripts.

this is very annoying when the log fills up the whole available diskspace

the code posted above is the only stacktrace available... I will try to find the code, that triggers it and post it in the issue tracker

12-24-2009, 01:17 PM
What I sent you is the full stack trace in the logs. These appear so rapidly that the logs fill up in no time.

12-24-2009, 01:37 PM
Hi All -

(sorry if this is a duplicate post, I thought I posted this yesterday, but my post never made it to the forums, so I'm trying again)

My experience is with glassfish v2.1 only. This happens immediately after undeploying and redeploying an application.

For a software patch to work around this issue, see:


Which also references:


I have not tried this patch w/Quercus 4.0.2. With Quercus 4.0.1, this patched the issue (the new heap message shows up in the logs as expected upon redeploy of the application), I did not see anything else break..


12-26-2009, 02:00 PM
the patch works for me in 4.0.2, but its a bad idea to do it this way, because its not resolving the initial coding error, but just hides the symptoms .

Dominik Dorn

12-27-2009, 08:58 PM
Hi Dominic -

I agree with you, what I put together masks the issue, but at least it allowed me to continue my development efforts.

As I noted on the glassfish users mailing list, it's not at all clear to me how _heap becomes null. Since this issue is easily duplicated in glassfish, and presumably doesn't happen in other containers (an assumption I'm making, since there are no complaints about this particular exception happning in other containers), it seems to point to a glassfish/quercus interaction issue triggered by undeploy/redeploy.

What version of glassfish are you using? I'm using an older version (v2.1), perhaps this issue doesn't exist in the latest versions of glassfish.


01-18-2010, 10:10 PM
I'm using latest v3.

I have a theory: The heap is statically assigned per jvm and first deployment.
When undeploying this reference gets set to null, however the static variable still remains. When redeploying the heap is not initialized again and the NPE gets triggered.

03-06-2010, 10:32 PM
if your theory is correct, would not that affect all redeployments?

I ask this because I redeploy web apps without trouble - so I have a hard time thinking this is the only contributing factor.

04-13-2010, 02:10 PM
I think I have fixed the issue

at least, with my fix I can successfully deploy + undeploy + deploy PHP/quercus apps without the error being triggered (tried it 10 times in a loop for now
for i in `seq 1 1 10`; do asadmin deploy . ; sleep 2; curl http://localhost:8080/; asadmin undeploy htdocs; sleep 2; done

@pbelb: could you try if the fix works for you?


04-16-2010, 07:15 PM
Hi domdom,

You are correct that the AlarmThread is the culprit. From my understanding, it appears that Tomcat is not closing a webapp's Threads (can they?) on a undeploy, and the AlarmThread class is accessing an uninitialized Alarm class (Tomcat classloaders unloaded the original Alarm class). I'll be submitting a fix in for 4.0.7. The main concern is making sure that we're not closing the Alarm Thread when Quercus is running under Resin :).

04-17-2010, 03:42 PM
Both threads, the AlarmThread and the CoordinatorThread stay running even when the app is undeployed.

Does Resin share threads accross apps?
If not, the safest way to clean this up would be a ServletContextListener that creates the threads on WebApp Start and destroys them on undeploying of the app.
This listener could also do the check for Resin I think and we would be on the save side.

Neither Tomcat nor Glassfish or JBoss do close threads that are still running on App undeployment ... they expect the application to do the cleanup.

04-28-2010, 08:11 PM
Fixed for 4.0.7.