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