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 > > > > >
