You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2011/07/20 22:46:55 UTC
Re: [OT] Tomcat 7 parallel deployment and PermGen Heap Space
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 7/20/2011 4:25 AM, Mark Thomas wrote:
> You need to de-register the driver you registered. However, that
> won't be causing the leak since Tomcat already did the clean up for
> you. Time to get the profiler out.
Quick question: I get these JDBC Driver messages from Tomcat when I
undeploy, but my code does not register the driver itself... Tomcat does
via a <Resource> defined in context.xml. Is that driver registered with
the WebappClassLoader and therefore considered "registered" by the webapp?
I've been irritated by this behavior for a while because I feel like the
container is performing the registration of the driver, but expecting
the webapp to perform the de-registration.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4nPr8ACgkQ9CaO5/Lv0PCtawCglncNAXh36PhsbX7RumBEY7UK
8OgAni40dlStbgDSEtskmROivDqPvO0b
=9j/G
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat 7 parallel deployment and PermGen Heap Space
Posted by Sylvain Laurent <sy...@m4x.org>.
My personal advice with the Oracle driver is to put it at the server level, not at the webapp level.
For instance if you use the query timeouts, oracle JDBC spawns a Thread to handle the timeouts, and there is no way to properly stop this thread so tomcat will continue complaining about leaking a classloader...
With the driver at the server level, the warnings will disappear and your webapp won't leak (or at least not because of the JDBC driver).
Sylvain
On 20 juil. 2011, at 22:59, Mark Thomas wrote:
> On 20/07/2011 21:46, Christopher Schultz wrote:
>> Mark,
>>
>> On 7/20/2011 4:25 AM, Mark Thomas wrote:
>>> You need to de-register the driver you registered. However, that
>>> won't be causing the leak since Tomcat already did the clean up for
>>> you. Time to get the profiler out.
>>
>> Quick question: I get these JDBC Driver messages from Tomcat when I
>> undeploy, but my code does not register the driver itself...
>
> The code might not, but registration is triggered by the application
> including the JAR. Just putting a JAR with a JDBC driver and the
> appropriate content in META-INF/services is enough to trigger
> registration with the JVM. Tomcat has nothing to do with this.
>
>> Tomcat does
>> via a <Resource> defined in context.xml. Is that driver registered with
>> the WebappClassLoader and therefore considered "registered" by the webapp?
>
> No. It is registered with the DriverManager. It is loaded by the
> WebappClassLoader which triggers the potential memory leak.
>
>> I've been irritated by this behavior for a while because I feel like the
>> container is performing the registration of the driver, but expecting
>> the webapp to perform the de-registration.
>
> The META-INF/services mechanism does not provide automatic
> de-registration so the app has to take care of it.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat 7 parallel deployment and PermGen Heap Space
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 7/20/2011 4:59 PM, Mark Thomas wrote:
> On 20/07/2011 21:46, Christopher Schultz wrote:
>> Mark,
>>
>> On 7/20/2011 4:25 AM, Mark Thomas wrote:
>>> You need to de-register the driver you registered. However, that
>>> won't be causing the leak since Tomcat already did the clean up
>>> for you. Time to get the profiler out.
>>
>> Quick question: I get these JDBC Driver messages from Tomcat when
>> I undeploy, but my code does not register the driver itself...
>
> The code might not, but registration is triggered by the application
> including the JAR. Just putting a JAR with a JDBC driver and the
> appropriate content in META-INF/services is enough to trigger
> registration with the JVM. Tomcat has nothing to do with this.
I was about to boldly state that I didn't have a JDBC driver in my
webapp's lib directory. Fortunately for me, I triple-checked first to
make sure that wasn't the case and, for some reason, the driver had
snuck into that directory. In my webapp's source, the JAR file was
sitting there participating in the build process, yet not under source
control. I must have done something stupid at some point. Fortunately,
this is dev and not prod :)
So, I have saved myself the embarrassment of stating that my webapp
/absolutely does not/ have a JDBC driver in it, opting for the equally
embarrassing "I should have checked my setup before publicly complaining
about Tomcat's behavior" :)
>> Tomcat does via a <Resource> defined in context.xml. Is that driver
>> registered with the WebappClassLoader and therefore considered
>> "registered" by the webapp?
>
> No. It is registered with the DriverManager. It is loaded by the
> WebappClassLoader which triggers the potential memory leak.
Er, that's what I meant.
>> I've been irritated by this behavior for a while because I feel
>> like the container is performing the registration of the driver,
>> but expecting the webapp to perform the de-registration.
>
> The META-INF/services mechanism does not provide automatic
> de-registration so the app has to take care of it.
I don't use META-INF/services but it's obvious what the problem is, here.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4toxYACgkQ9CaO5/Lv0PDMpwCgpHgHx1c9APsMLNirnetR7/p+
KEYAnilC8kwpxrJ74ffWtJvlysP+J3C/
=5pO+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Tomcat 7 parallel deployment and PermGen Heap Space
Posted by Mark Thomas <ma...@apache.org>.
On 20/07/2011 21:46, Christopher Schultz wrote:
> Mark,
>
> On 7/20/2011 4:25 AM, Mark Thomas wrote:
>> You need to de-register the driver you registered. However, that
>> won't be causing the leak since Tomcat already did the clean up for
>> you. Time to get the profiler out.
>
> Quick question: I get these JDBC Driver messages from Tomcat when I
> undeploy, but my code does not register the driver itself...
The code might not, but registration is triggered by the application
including the JAR. Just putting a JAR with a JDBC driver and the
appropriate content in META-INF/services is enough to trigger
registration with the JVM. Tomcat has nothing to do with this.
> Tomcat does
> via a <Resource> defined in context.xml. Is that driver registered with
> the WebappClassLoader and therefore considered "registered" by the webapp?
No. It is registered with the DriverManager. It is loaded by the
WebappClassLoader which triggers the potential memory leak.
> I've been irritated by this behavior for a while because I feel like the
> container is performing the registration of the driver, but expecting
> the webapp to perform the de-registration.
The META-INF/services mechanism does not provide automatic
de-registration so the app has to take care of it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org