Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#56 NullPointerException in isLoggable

open
nobody
None
5
2014-03-10
2007-09-16
Anonymous
No

I get the following exception in c3p0 v0.9.1.2:

Exception in thread "Timer-0" java.lang.NullPointerException
at com.mchange.v2.log.log4j.Log4jMLog$Log4jMLogger.isLoggable(Log4jMLog.java:257)
at com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(BasicResourcePool.java:1961)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)

I'm using Hibernate with the following configuration:

hibernate.c3p0.max_size 100
hibernate.c3p0.min_size 5
hibernate.c3p0.timeout 100
hibernate.c3p0.max_statements 0
hibernate.c3p0.idle_test_period 100
hibernate.c3p0.acquire_increment 2

and c3p0.properties with:

preferredTestQuery select 1
unreturnedConnectionTimeout 6
debugUnreturnedConnectionStackTraces true

and

log4j.category.com.mchange=INFO
log4j.category.com.mchange.v2.resourcepool.BasicResourcePool = DEBUG

I think this exception prevents c3p0 from cleaning connections and might be the cause of my queries failing after the mysql 8-hours connection timeout (if not, I might submit another bug :)

Discussion

  • Logged In: NO

    I get this Exception as well, but only after I undeploy the webapp. It looks to me like C3P0 creates some Threads here " com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(Ba
    sicResourcePool.java:1961)", and the Threads are not aware of the fact that the webapp has been undeployed. The app server becomes very unstable after a few of these webapps are deployed and undeployed. Our staging and production servers have to be Killed and restarted frequently due to this issue. It would be good to notify these Threads when a webapp is undeployed, so that they can shutdown cleanly and the container does not become unstable and produce all of these NullPointerExceptions.

    I think this problem is related, but if the problem I am describing is not related to the original post, please let me know so I can create a new bug report. I don't want to Hijack your bug.

    -Stephen Wick

     
  • HI,

    I did not do undelopy action and get this error again. There are only one place different with the committor.

    I do not config log4j.category.com.mchange=INFO and I think that this should not impact anything, right?

    miming@cisco.com

     
  • HI,

    I did not do undelopy action and get this error again. There are only one place different with the committor.

    I do not config log4j.category.com.mchange=INFO and I think that this should not impact anything, right?

    miming@cisco.com

     
  • We think we have found a pretty nasty race condition in C3P0, which causes the problem 1795823 (NullPointerException in logger) and also a new problem still not reported (ConcurrentModificationException) when stopping/undeploying a C3P0 application under Tomcat 6.

    The resourceDestroyer thread (inside the close method of BasicResourcePool) is executed asynchronously and takes some time to complete, so if you start it immediately before undeploying the application it is possible that the Tomcat WebappClassLoader starts clearing all the references to the loaded classes (including C3P0 ones) WHILE the resourceDestroyer thread is still running. As a consequence, the logger reference is found null by resourceDestroyer and a NullPointerException is raised.

    As a proof of what I said, we have implemented a ContextListener which is called by Tomcat every time an application is stopped or undeployed, and we have added a sleep right after calling the DataSources.destroy() in C3P0. This way we give time to the resourceDestroyer to complete his job BEFORE the Tomcat WebappClassLoader nullifies references inside C3P0.

    We have written a simple test performing a deploy/stop/undeploy cycle of a C3P0 application. With a zero-seconds sleep, our test raises the null-pointer exception once out of ten cycles. With a 20 secs sleep, the test has completed 2500 cycles with no null-pointer exceptions at all (we had to stop it manually).

    By the way, with a zero-seconds sleep, we also had another problem during the stop/undeploy of C3P0 applications: a java.util.ConcurrentModificationException was raised by Tomcat
    WebappClassLoader when it tried to clone the references map in the method clearReferences(). This problem also disappears when we set a 20 secs sleep, so we believe that it is caused by the same race condition raising the NullPointerException.

    We suggest to modify the close method of BasicResourcePool adding a join to the resourceDestroyer thread. We would do it ourselves (and release the patch to the community) if only we had a build that works. The one we have fails to build C3P0 with several compilation errors....

    Thanks for your support.