On 21/11/2018 11:00, Gilles SCHLIENGER wrote: > Hi all, > > We are using Tomcat 9 and parallel deployment. > > I use a connection pool defined in the xml context (myApp##1.xml, > myApp##2.xml in my exemple) > > I have the following problem : > - I have myApp##1.war deployed using a connection pool (configured in > myApp##1.xml) > - I deploy myApp##2.war (using a connection pool defined in myApp##2.xml) > - when the last session in myApp##1 expires, myApp##1 is automatically > undeployed (I have undeployOldVersions="true" in server.xml for the Host) but > the connections opened by myApp##1 are not closed. > > I used the Tomcat configuration from the example in : > https://tomcat.apache.org/tomcat-9.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP_2)_Configurations > > <Resource name="jdbc/integrationGG" auth="Container" > type="javax.sql.DataSource" > maxTotal="100" maxIdle="30" maxWaitMillis="10000" > destroy-method="close" > username="postgres" password="password" > driverClassName="org.postgresql.Driver" > > url="jdbc:postgresql://localhost:5432/postgres?stringtype=unspecified"/> > > During undeploy, I get the following messages : > > 21-Nov-2018 11:42:54.795 AVERTISSEMENT > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web > application [myApp##1] registered the JDBC driver [org.postgresql.Driver] but > failed to unregister it when the web application was stopped. To prevent a > memory leak, the JDBC Driver has been forcibly unregistered.
That is a warning you should be able to fix by unregistering the JDBC driver in a ServletContextListener. > 21-Nov-2018 11:42:54.800 AVERTISSEMENT > [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The > web application [myApp##1] appears to have started a thread named [Abandoned > connection cleanup thread] but has failed to stop it. This is very likely to > create a memory leak. Stack trace of thread: > java.base@10.0.1/java.lang.Object.wait(Native Method) > java.base@10.0.1/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) > com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:64) > java.base@10.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) > java.base@10.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) > java.base@10.0.1/java.lang.Thread.run(Thread.java:844) That is a thread started by the MySQL driver. There should be an API provided by the MySQL driver that you can call to stop the thread (again in a ServletContextListener) although I'd expect that to happen automatically as part of unloading the driver. If there is no way to stop the thread then that would be a bug in the MySQL driver. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org