Thanks Mark for your answer

Here is what I found in case someone has the same problem.

When you use parallel deployment, you should not use a connexion pool in the 
context.xml file
Once the connexions are opened, they stay opened until Tomcat shuts down, 
whatever configuration you try.
So everytime you deploy a new version of your webapp, new connexions are being 
opened.
So we will configure our connexion pools directly in our Spring webapp. This 
way, the connexions are closed when the webapp is undeployed.

The warning/error messages are not actually linked to the connexions not closed.
To ovoid these messages, you can:
- move the jars (connexion pool, drivers...) into TOMCAT/lib
- Have a ServletContextListener that calls 
AbandonedConnectionCleanupThread.checkedShutdown();

Regards
Gilles

-----Message d'origine-----
De : Mark Thomas [mailto:ma...@apache.org] 
Envoyé : mercredi 21 novembre 2018 14:18
À : Tomcat Users List; Gilles SCHLIENGER
Objet : Re: Connection pool and parallel deployment problem

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