You can try HikariCP, it is mentionned in the Spring documentation
-----Message d'origine----- De : HeeGu Lee [mailto:elfhazardw...@gmail.com] Envoyé : mardi 27 novembre 2018 10:28 À : Tomcat Users List Objet : Re: Connection pool and parallel deployment problem I'm glad to solve problem. But I am concerned that the C3p0 is not updated since 2015. Let's hope for a better library. Bye~ 2018년 11월 27일 (화) 오후 6:20, Gilles SCHLIENGER <gilles.schlien...@cncc.fr>님이 작성: > Thanks, > > I don't have this problem using C3p0 > > Parallel deployment is working fine so far, especially now that we will > use connection pools configured inside the webapp (no more context xml file) > > Regards > Gilles > > -----Message d'origine----- > De : HeeGu Lee [mailto:elfhazardw...@gmail.com] > Envoyé : mardi 27 novembre 2018 10:17 > À : Tomcat Users List > Objet : Re: Connection pool and parallel deployment problem > > 1. JMX registration is call by BasicDataSource of apache commons-dbcp2 > library. > It is hidden inside and can not be controlled. > > The name of the spring bean is referenced as part of the JMX name. > You can change the bean name for each distribution. > But that is not smart. > > 2. Usually, JMX is use for system monitoring. > Using tool like grafana, you will see jvm heap momory, running thread > count, network traffic of Tomcat. > > > 2018년 11월 27일 (화) 오후 6:03, Gilles SCHLIENGER <gilles.schlien...@cncc.fr>님이 > 작성: > > > Thanks a lot Heegu, > > > > I looked at your project on github. > > 1. Which part of the code is exporting JMX beans ? Is it the @ManagedBean > > annotation ? > > > > 2. What do you use JMX for ? > > > > Thanks again > > Regards > > Gilles > > > > > > -----Message d'origine----- > > De : HeeGu Lee [mailto:elfhazardw...@gmail.com] > > Envoyé : mardi 27 novembre 2018 08:36 > > À : Tomcat Users List > > Objet : Re: Connection pool and parallel deployment problem > > > > Dear Gilles, > > > > I apologize for the delay in reply. > > > > I make simple webapp and upload to github. In project, my test result is > > included. > > > > https://github.com/elfhazardwork/dbcp2-test > > > > Tomcat's parallel deploy mechanism is deploy new version before undeploy > > old. > > So, If your webapp is use JMX, bean name will duplicate and crush. > > > > The connection pool is used where the developer does not explicitly > declare > > JXM. > > So this is a Tomcat bug. > > Otherwise, you must set JMX bean name dynamically. > > > > I hope this helps. > > > > > > 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire <yahoono...@gmail.com>님이 작성: > > > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > > <gilles.schlien...@cncc.fr> wrote: > > > > > > > > Hi, > > > > I understand your needs, but what is your problem, since you don't > use > > > parallel deployment ? > > > > Your connections are not closed but they will not be recreated when > you > > > deploy your webapp again, so there should be no problem ? > > > > > > > > Gilles > > > > > > > > > > I added my 2c because I am seeing what you describe here > > > > > > > > - 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) > > > > > > > > > Yes I know you are using parallel deployment and I am not, but that > > > doesn't necessarily mean that the problem you see is limited to only > > > parallel deployment. Maybe the problem can be simplified to " > > > Tomcat considers the connections closed, the database doesn't." > > > > > > I could well be wrong, I'll leave it up to the gurus to decide :) > > > > > > > > > > -----Message d'origine----- > > > > De : Chris Cheshire [mailto:yahoono...@gmail.com] > > > > Envoyé : lundi 26 novembre 2018 15:27 > > > > À : Tomcat Users List > > > > Objet : Re: Connection pool and parallel deployment problem > > > > > > > > I'm interested in what solution there is for this because I have the > > > > exact same problem but without parallel deployment. > > > > > > > > [snip] > > > > > > > > On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER > > > > <gilles.schlien...@cncc.fr> wrote: > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > My results are the same. Using mysql, connection pools defined in > > > > server.xml (for user realm for access control to host manager app) > and > > > > in my context.xml for my application. When I use the host-manager to > > > > reload an app, the connections are closed (no abandoned connection > > > > warnings) but not released. It is no until I stop tomcat completely > > > > and restart it that the connections are released in mysql. This has > > > > been the case for tomcat 7, 8.5 and 9 versions, with constant updates > > > > of mysql 5.7 and its driver, using both the apache connection pool > and > > > > the tomcat connection pool. The driver lives in the tomcat/lib > > > > directory (since it is needed for the user realm datasource). > > > > > > > > > > > > > -----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: > > > > > > > > [snip] > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > Should we be using checked or unchecked shutdown? > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
