How to redeploy hibernate-c3p0 project to tomcat 7 without getting weird c3p0 errors
If the project is redeployed via netbeans to tomcat 7 then I get errors like
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1600)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at com.mchange.v2.resourcepool.BasicResourcePool.checkIdleResources(BasicResourcePool.java:1481)
at com.mchange.v2.resourcepool.BasicResourcePool.access$2000(BasicResourcePool.java:32)
at com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(BasicResourcePool.java:1964)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Exception in thread "Timer-5" java.lang.NoClassDefFoundError: com/mchange/v2/resourcepool/BasicResourcePool$AsyncTestIdleResourceTask
at com.mchange.v2.resourcepool.BasicResourcePool.checkIdleResources(BasicResourcePool.java:1481)
at com.mchange.v2.resourcepool.BasicResourcePool.access$2000(BasicResourcePool.java:32)
at com.mchange.v2.resourcepool.BasicResourcePool$CheckIdleResourcesTask.run(BasicResourcePool.java:1964)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.ClassNotFoundException: com.mchange.v2.resourcepool.BasicResourcePool$AsyncTestIdleResourceTask
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1714)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
... 5 more
We got another weird error today when we tried to redeploy the project to tomcat 7
[5:07:02 PM] Nitin - Webscraper/Tester,Java/PHP developer: java.lang.NoClassDefFoundError: com/mchange/v2/lang/VersionUtils
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:104)
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:65)
com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:62)
com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:531)
com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:78)
org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161)
org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1700)
org.hibernate.loader.Loader.doQuery(Loader.java:801)
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
org.hibernate.loader.Loader.doList(Loader.java:2542)
org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2276)
org.hibernate.loader.Loader.list(Loader.java:2271)
We've been getting such strange errors since quite a while. When we try to debug, we find classes that already exist.
What I can imagine is to abort connection threads with the c3p0 pool, which either won't be destroyed properly when redeployed, or may have some kind of active connection, or something similar.
Are there any guidelines on how to redeploy a project like this that uses hibernate and c3p0? Is there some code I should write on contextDestroyed
to properly close c3p0 streams?
source to share
I also had an issue with the same issue and could see below warning in my tomcat console
Jul 30, 2014 3:20:16 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads WARNING. The web application [/ rmlcrm] appears to have started a thread named [C3P0PooledConnectionPoolManager [identityToken-> 1hge50p9311d8syo1hfjimz | 19ddf1db] -HelperThread- # 0] but could not stop it. This will likely lead to a memory leak. Stack trace: java.lang.Object.wait (native method) com.mchange.v2.async.ThreadPoolAsynchronousRunner $ PoolThread.run (ThreadPoolAsynchronousRunner.java:635)
I read a lot to find a solution to this and came across the post Hibernate: OutOfMemoryError: PermGen space
One of the comments in Nicholas Hemley's post suggested adding a custom ServletContextListener and explicitly closing C3P0 connections in the listener's contextDestroyed () method, which will be executed when the application is not deployed.
We didn't use the code in exactly the same way we didn't want to hide with C3P0. But we realized that we are not closing the hibernate sessionFactory anywhere in our application. We have added code to close the hibernate factory session in the context of the Destroyed () ServletContextListener. Now we have no error and no warning in tomcat console.
You can also read Hibernate: Closing a factory session does not close the connection pool c3p0
source to share
a few thoughts:
1) if you have configured the hibernate app lifecycle to map to the web app lifecycle (definitely true if hibernate and c3p0 libs live in your web app libs directory, which might seem to be true even if not), you absolutely need to the c3p0 pools were destroyed before the application was reused, which often means the contextDestroyed
. in hibernate-talk mode, this SessionFactory wraps the connection pool; make sure your SessionFactory app is closed () when your app shuts down on hot redeploy. there must be symmetry: either in contextInitialized
, or lazily on the first request, your SessionFactory must be initialized. it should be destroyed when the application exits.
2) the latest (still preview) version of c3p0 has some tweaks to reduce the chances of infection between c3p0 threads and objects derived from legacy ClassLoaders web applications, especially if c3p0 is loaded by a non-web application with a specific ClassLoader (for example, if c3p0 libs live in $ CATALINA_HOME / lib, not in the webapp lib directory). if you want to go to pre-pre-pre-check [latest is now c3p0-0.9.5-pre5 ] try the following new config settings:
c3p0.privilegeSpawnedThreads=true
c3p0.contextClassLoaderSource=library
hope this helps!
source to share