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

Reply via email to