On 2/13/2015 11:23 AM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 2/12/15 12:59 PM, David kerber wrote:
On 2/12/2015 12:48 PM, Cris Berneburg - US wrote:
-----Original Message----- From: David kerber
[mailto:dcker...@verizon.net] Sent: Thursday, February 12, 2015
9:40 AM To: Tomcat Users List Subject: Re: tomcat severe error
when shutting down service but startup is clean
On 2/12/2015 9:06 AM, Wirth, Kevin wrote:
I keep getting these weird tomcat errors on shutdown on a newly
built system using tomcat 7.0.57 on a windows 2012 server with
jdk 1.7 that I can't figure out. This is the catalina log: Feb
12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc SEVERE: The web application [/identityiq]
registered the JDBC driver
[com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to
unregister it when the web application was stopped. To prevent
a memory leak, the JDBC Driver has been forcibly unregistered.
Feb 12, 2015 8:54:31 AM
org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads SEVERE: The web application
[/identityiq] appears to have started a thread named [Thread-3]
but has failed to stop it. This is very likely to create a
memory leak.
I ran into this a while back, and it means exactly what it
says: the db driver is being registered (loaded), but not
being unloaded. I fixed it by putting the db driver unload
commands in a contextDestroyed method.
David
I have the same issue as Kevin. What "unload commands" code did
you call in the contextDestroyed method? Are those methods
"universal"? The reason I ask is because we use different ODBC
drivers for different environments.
I call this code from my .contextDestroyed method (I didn't write
it, I copied it from somewhere on the web):
public static void unRegisterDrivers() { try { for (
Enumeration<Driver> drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log the
exception */ } }
This is likely to over-reach in many scenarios. YMMV.
Also, Tomcat already de-registers drivers for you. So, this probably
isn't really changing anything.
We manage the pooling in our application, and don't use any of TC's
connection pooling. This is largely because several years ago (long
enough ago that the then-current version of TC was 5.5.25) the app was
moved from another servlet container that either didn't have pooling, or
it was harder to use than it was to write out own. I wasn't in on the
initial development, but did the port to TC. And at the time I did the
port, I had no idea about TC's connection pooling, so continued with our
own pooling implementation.
Until I did this, I could not get rid of the memory leak warnings. If
there is another way, I couldn't find it at the time I was messing with
it...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
