Hi Christopher, Thanks for your email.
About connection pools not being closed, maybe the connection pool is closed but the connections to the database are not. Here are the tests I did: + TEST 1: - I deploy my war - I login to my webapp - I check on my postgresql and mysql database that connections have been opened (select...) - I undeploy my webapp through the manager webapp - I check that the connections are still opened - Tomcat is still running - I redeploy the exact samed webapp and login to my application - No other connection is being opened + TEST 2: - I deploy my war - I login to my webapp - I check on my postgresql and mysql database that connections have been opened (select...) - I deploy a new version of my application and login with another browser - I check on my postgresql and mysql database that new connexions have been opened (they doubled) - I undeploy the first version of the webapp - I check on my postgresql and mysql database and all connections are still opened (even if I wait for a long time) For tests 1 and 2, I used C3p0, DBCP2 and even HikariCP + TEST 3: - I configure my connection pools directly in my Spring application with an external configuration file - I do the same as TEST 2 -> this time, I can see the number of database connections going down when I undeploy the first version of the webapp Thanks again Chris if you have any advice Regards Gilles -----Message d'origine----- De : Christopher Schultz [mailto:ch...@christopherschultz.net] Envoyé : samedi 24 novembre 2018 17:19 À : users@tomcat.apache.org Objet : Re: Connection pool and parallel deployment problem -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gilles, On 11/23/18 05:07, Gilles SCHLIENGER wrote: > 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 Why not? > Once the connexions are opened, they stay opened until Tomcat > shuts down, whatever configuration you try. I would expect that any connection pool created for a context (or instance of a context, when parallel deployments are being done) would be shut-down when the application is undeployed. Are you actually undeploying the old context? It doesn't happen automatically IIRC. > So everytime you deploy a new version of your webapp, new > connexions are being opened. This is expected. How could it work, otherwise? > So we will configure our connexion pools directly in our Spring > webapp. This way, the connexions are closed when the webapp is > undeployed. That's one way to solve the issue, but not the only way. > 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(); The Connector/J devs haven't been able to understand how ClassLoaders work, and have never really fixed that long-standing bug in a satisfying way as far as I know. But you should always use a ServletContextListener to attempt to shut-down the AbadonedConnectionCleanuopThread. BTW that thread does not work as documented. It's claimed that it doesn't start unless you issue a query with a timeout, but it always starts whether or not you use queries with timeouts. It's frustrating. - -chris > -----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-how to.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.clearReferencesThrea ds >> 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.j ava:151) >> >> com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionC leanupThread.java:64) >> java.base@10.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(Th readPoolExecutor.java:1135) >> >> java.base@10.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(Thre adPoolExecutor.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 > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv5edkACgkQHPApP6U8 pFhb9xAApqaVz+RVrKVx4Cmv7PwHl10wDeQeQFlmPXO5ydafWWOtUb5hHcuifkyE 7p+2NwtS6PoAIMMVwg4De+dedJl3sGb/n1eT/HOPmivxRL9Dl47D32OfM6nJiHzJ mesayADVYr+wCzCYavfsj/Fkp2aiNAESWwtnzjgDlgLV8nOaj8YTknLge83pnfNP XaMNDlChRt0OW1LewnRYK7KXCVOB3f7ZpxZK0jD8c5BZRLRgNrcyqKsWJsh289Ym OmF3ToCw9Wv/3Jq6aE8AFK6wjA384ocuVqYAbC0IvBbXqFhE9lz1/vekWFhfltS0 Bi2aTtNxDFhHjJsbhEQPCnArjuoA75Da1eqSJvLiXdk99slDoB1q3umpxTkRy4nQ 4nIkywZcSek8o4Iq+j7tVhF7PdvtYXfrwIotuYCupni+jzos3b57q1zpZpqcCuce Vuc2G/aM0pw+DYXUaeUTIojrQGmtWmmd94zzX6gUXz6JV0vGj9gtqN7HVqrJX3dR uISPyk0ca1Ds4KvUkNoyO3bg/bhpgn4YpCVUOU9zt6ZFYCOnn29VATddDP/uujR7 uGvh7129vkyAQwOI1N68EiCj6zI4RQndJcgQf/l5gulBTMi4T4cDjn9sNT7UETkK tsuQ6mMSQYNo4N0CL+279576yNOPzH2aUZ+X7GowdQnB2X9PYhc= =IW4H -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
