Here is the code to shut down the pools. When I was running a single pool the
issue did not occur. It's when I added the second pool that the issue started.
Arrays.asList(universalConnectionPoolManager.getConnectionPoolNames())
.forEach(poolName -> {
try {
universalConnectionPoolManager
.destroyConnectionPool(poolName);
} catch (Exception e) {
exceptionHandler.handleError(
e,
String.join(
":",
"Destroy Connection Pool Error",
poolName));
}
});
The jdbc driver and connection pool .jar files are in the tomcat lib folder and
not in the applications lib folder.
I never tried Tomcat's version of connection pooling.
Thank you,
Chris Brown
Systems Consultant
National Council on
Compensation Insurance
901 Peninsula Corporate Circle
Boca Raton, FL 33487-1362
(P) 561-893-2324
chris_br...@ncci.com
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, March 07, 2016 10:33 AM
To: Tomcat Users List
Subject: Re: Tomcat 7 Web Service Shutdown Can't Stop Threads
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris,
On 3/7/16 9:51 AM, Chris Brown wrote:
> Tomcat is shutting down the web service when I deploy a new .war file.
Okay. You said you were closing the connection pool, though:
On 3/4/16 2:13 PM, Chris Brown wrote:
> I added a ServletContextListener to our web service. On the
> contextDestroyed method we destroy the connection pools. Our web
> service uses 2 connection pools.
So, how, precisely, are you shutting those pools down?
> There is no documentation on the threads and what they are for in
> oracle or tomcats documentation.
Tomcat would not contain information on a Vendor's product. A quick Google
search for "oracle ojdbc7 ucp-worker-thread" yields the following very relevant
result:
http://stackoverflow.com/questions/9671270/oracle-ucp-driver-and-tomcat-
threads-failing-to-stop
Also, searching for the OJDBC manual has a FAQ which mentions threads and their
lifetimes:
http://www.oracleimg.com/technetwork/articles/sql/jdbc-faq-090281.html
> The threads are not shutting down and they stay alive when the web
> service is shut down. I know this because I count the number of
> threads each time the web service context is destroyed and number
> keeps growing for each deployment of the .war file.
Oh, I believe you that they are piling up.
Is there a particular reason you are using Oracle's connection pool rather than
the one provided by the container (Tomcat)? Tomcat's pool won't leak like this
one does. Then again, the Oracle driver itself might still leak, but it will be
less leaky.
It's possible that the driver needs to be loaded before the application in
order to avoid pinning the ClassLoader into memory.
That can be done with Tomcat's configuration, but I'd only recommend that you
do this if nothing else is working.
I'd still like to know that those other threads (e.g. Thread-0) are doin g.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlbdnygACgkQ9CaO5/Lv0PCClgCfUmDNGz68sT6beiMOwx2Pkewb
UGcAoJNpSVJ8wagZRiGZMS9LxO3g0KY9
=qWGg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
________________________________
The information contained in this e-mail message is intended only for the
personal and confidential use of the recipient(s) named above. This message may
be an attorney-client communication and/or work product and as such is
privileged and confidential. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended recipient,
you are hereby notified that you have received this document in error and that
any review, dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.
