[OT] Re: Connection pool and parallel deployment problem
On 27.11.2018 10:13, Esther Montes wrote: Buenas tardes nomás kiero saber si tengo que ir otra vez al banco para para q me meten unas claves o asi me va a entregar los depósitos Either this is some fiendishly elaborate new scam method of which I haven't heard before, or else there is someone hopelessly confused out there.. El mar., 27 de nov. de 2018 1:03 AM, Gilles SCHLIENGER < gilles.schlien...@cncc.fr> escribió: 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 님이 작성: On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER 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 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, driv
RE: Connection pool and parallel deployment problem
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 님이 작성: > 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 님이 > 작성: > > > 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 님이 작성: > > > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > > 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 > > > > wrote: > > > > > > > > > > Hi Christopher, > > > > > > > > &g
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 님이 작성: > 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 님이 > 작성: > > > 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 님이 작성: > > > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > > 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 > > > > 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
RE: Connection pool and parallel deployment problem
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 님이 작성: > 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 님이 작성: > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > 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 > > > 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 hav
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 님이 작성: > 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 님이 작성: > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > 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 > > > 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 connecti
Re: Connection pool and parallel deployment problem
Buenas tardes nomás kiero saber si tengo que ir otra vez al banco para para q me meten unas claves o asi me va a entregar los depósitos El mar., 27 de nov. de 2018 1:03 AM, Gilles SCHLIENGER < gilles.schlien...@cncc.fr> escribió: > 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 님이 작성: > > > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > > 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 > > > 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
RE: Connection pool and parallel deployment problem
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 님이 작성: > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > 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 > > 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- >
RE: Connection pool and parallel deployment problem
Just one more thing I forgot to mention : When I see the conections opened on databases using an sql query, I also see the Threads of the connection pool still present using jConsole to connect to tomcat Gilles -Message d'origine- De : Chris Cheshire [mailto:yahoono...@gmail.com] Envoyé : lundi 26 novembre 2018 18:04 À : Tomcat Users List Objet : Re: Connection pool and parallel deployment problem On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER 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 > 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-stand
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 님이 작성: > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER > 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 > > 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 0
Re: Connection pool and parallel deployment problem
On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER 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 > 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
RE: Connection pool and parallel deployment problem
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 -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 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
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 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
RE: Connection pool and parallel deployment problem
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 >> >> >> > maxTotal="100" maxIdle="30" maxWaitMillis="1" >> destroy-method="close" username="postgres" password="password" >> driverClassName="org.postgresql.Driver&
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 >> >> >> > maxTotal="100" maxIdle="30" maxWaitMillis="1" >> 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.u
RE: Connection pool and parallel deployment problem
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 > > type="javax.sql.DataSource" >maxTotal="100" maxIdle="30" maxWaitMillis="1" > 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
RE: Connection pool and parallel deployment problem
Are you talking about parallel deployment or connection pools ? Parallel deployment is in Tomcat since Tomcat 7 Gilles -Message d'origine- De : HeeGu Lee [mailto:elfhazardw...@gmail.com] Envoyé : mercredi 21 novembre 2018 13:24 À : Tomcat Users List Objet : Re: Connection pool and parallel deployment problem I think it is good for your mental health not to use this feature. You just have to think of it as an experimental function like google chrome's about://flags. JMX has subscribe model. However, Tomcat is no ability to receive notifications. And most JDBC implementations are not interested in such features. Both Tomcat and DB vendors are not going to fix it. It's not a tragedy, it's just a comedy. 2018년 11월 21일 (수) 오후 8:00, Gilles SCHLIENGER 님이 작성: > 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 > > type="javax.sql.DataSource" >maxTotal="100" maxIdle="30" maxWaitMillis="1" > 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. > > ... > > 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) > > I have tested adding < destroy-method=close > but it did not change > anything > > Is this a bug ? > > Thanks for any help ! > > Regards > Gilles > >
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 > > type="javax.sql.DataSource" >maxTotal="100" maxIdle="30" maxWaitMillis="1" > 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
Re: Connection pool and parallel deployment problem
I think it is good for your mental health not to use this feature. You just have to think of it as an experimental function like google chrome's about://flags. JMX has subscribe model. However, Tomcat is no ability to receive notifications. And most JDBC implementations are not interested in such features. Both Tomcat and DB vendors are not going to fix it. It's not a tragedy, it's just a comedy. 2018년 11월 21일 (수) 오후 8:00, Gilles SCHLIENGER 님이 작성: > 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 > > type="javax.sql.DataSource" >maxTotal="100" maxIdle="30" maxWaitMillis="1" > 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. > > ... > > 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) > > I have tested adding < destroy-method=close > but it did not change > anything > > Is this a bug ? > > Thanks for any help ! > > Regards > Gilles > >
Connection pool and parallel deployment problem
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 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. ... 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) I have tested adding < destroy-method=close > but it did not change anything Is this a bug ? Thanks for any help ! Regards Gilles
