-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David,
On 2/13/15 11:33 AM, David kerber wrote: > 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:[email protected]] 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... I'm not sure at what point Tomcat started de-registering drivers. When it de-registers a driver, it gives you a warning. By you doing it yourself, you are avoiding the warning, of course. But if you de-register all drivers, you are also de-registering any drivers that were registered by different web applications, Tomcat's connection-pool, etc. It would be better to only de-register the driver(s) you actually registered in the first place. I haven't researched such things, but a reasonable way might be to do something like this: ClassLoader cl = Thread.currentThread().getContextClassLoader(); for(Driver driver : DriverManager.getDrivers()) if(cl.equals(driver.getClass().getClassLoader())) DriverManager.deregisterDriver(driver); This way, you only remove drivers you load yourself. Alternatively, you probably already know which drivers you have explicitly loaded, so you could explicitly unload them instead of flushing the whole DriverManager. Note: I have no idea if Driver objects get the proper ClassLoader assigned, but it's worth a try to get a bit more safety. If your web application is the only one loaded, feel free to wipe-out the DriverManager like that. But, if you need to operate in a shared environment, your technique above might negatively impact other code that relies on its driver not being forcibly un-loaded out from under it. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU3iw8AAoJEBzwKT+lPKRYu44QAJs8etPXC8CiQxlkPLnBY5lp A13W+Ibk2X7TX/y3oIIry7juiFWMWBrVKaxFuVEcBgI4P3lfQ5rZAbba44of9r2N RhXdwIepEgATD3E+LaRTAPuHOv5vZ2hhsj8GhlVp4caa2VCpY/iKL4Ax2w5vttrX 38Cp80eIXaLOl1M802bnoOI3s4NUaCo7+zWOAPXzZ1f1jyQx/H9Vbau90CcmQeIm t17BOYa3C88FDc2QGfrbucYNqRKYLlUQcGhP+tjtyBv7qcWvBMprUz7dvFhtNTHQ pEGWctPnJlza3e5quyQrFtLnLcAWlzKwvCxrCFhMDB6FeEpj21fFZYvrNKRHau+T Yr3ZQ03+PepqyT+graWSSd5ejCRNrmXeTgw/9r+KCimbBp40DbDqWFzWh7OH6OAN I++n5EOmH+XkXgFfgF63NlnSFyf60mLFNZs0X9hBEw9WbIj7FXuuKoJhsNoSlCQ+ U0n5YavLrc7jwxg00R1Lp51O5tVzdwItdK0wNUiR2iHu3/WjCjOKUJIC5FqITXKb 8Bd6S8ar+7mMC6riwp6zcjB4SMQnG5QKjGUsru7zoUmkStDwCFZ+xKkPeqgECIpf 7CasrGiBbX8JsdvZy+T03TiAwQC9xlag0JTfnApkZaJHvQjVuUEMBb3VCmqYK1Qm zLZcwp+Nogs998uL/2eR =4zOL -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
