help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
In case you didn't see the forum thread and could help with the below
issues.

https://community.jboss.org/message/716191 is a forum thread about
classloader leaks.

Text from the forum thread:

"
Application ClassLoader leaks:

HibernateAnnotationScanner keeps references to application’s ClassLoader
(minor issue): https://issues.jboss.org/browse/AS7-3734

javax.ws.rs.ext.FactoryFinder use application’s Class Loader which
causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735

javax.el.BeanELResolver.properties keeps references to undeployed
classes: https://issues.jboss.org/browse/AS7-3736

Threads ContextClassLoader leaks:

AWT AppContext / EventQueue ClassLoader Memory Leaks:
https://issues.jboss.org/browse/AS7-3733

sun.net.www.http.KeepAliveCache preventing classloader from being
garbage collected: https://issues.jboss.org/browse/AS7-3732

Threads ContextClassLoader leak caused by EJB passivation pool:
https://issues.jboss.org/browse/AS7-3737

ThreadLocal pseudo-leaks:

org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
on AS 7: https://issues.jboss.org/browse/RESTEASY-660
"

I have a fix for the JPA leak but not sure about the others.

The ejb passivation pool leak probably needs the TCCL to be cleared when
new threads are created for the GroupAwareBackingCacheImpl.

Scott
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Jaikiran Pai
Paul is looking into the EJB passivation pool CL leak issue.

-Jaikiran
On Monday 13 February 2012 11:29 PM, Scott Marlow wrote:

> In case you didn't see the forum thread and could help with the below
> issues.
>
> https://community.jboss.org/message/716191 is a forum thread about
> classloader leaks.
>
> Text from the forum thread:
>
> "
> Application ClassLoader leaks:
>
> HibernateAnnotationScanner keeps references to application’s ClassLoader
> (minor issue): https://issues.jboss.org/browse/AS7-3734
>
> javax.ws.rs.ext.FactoryFinder use application’s Class Loader which
> causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735
>
> javax.el.BeanELResolver.properties keeps references to undeployed
> classes: https://issues.jboss.org/browse/AS7-3736
>
> Threads ContextClassLoader leaks:
>
> AWT AppContext / EventQueue ClassLoader Memory Leaks:
> https://issues.jboss.org/browse/AS7-3733
>
> sun.net.www.http.KeepAliveCache preventing classloader from being
> garbage collected: https://issues.jboss.org/browse/AS7-3732
>
> Threads ContextClassLoader leak caused by EJB passivation pool:
> https://issues.jboss.org/browse/AS7-3737
>
> ThreadLocal pseudo-leaks:
>
> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
> "
>
> I have a fix for the JPA leak but not sure about the others.
>
> The ejb passivation pool leak probably needs the TCCL to be cleared when
> new threads are created for the GroupAwareBackingCacheImpl.
>
> Scott
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
That looked like an actual leak, some of the others don't as much but
the jury is still out.

On 02/13/2012 01:02 PM, Jaikiran Pai wrote:

> Paul is looking into the EJB passivation pool CL leak issue.
>
> -Jaikiran
> On Monday 13 February 2012 11:29 PM, Scott Marlow wrote:
>> In case you didn't see the forum thread and could help with the below
>> issues.
>>
>> https://community.jboss.org/message/716191 is a forum thread about
>> classloader leaks.
>>
>> Text from the forum thread:
>>
>> "
>> Application ClassLoader leaks:
>>
>> HibernateAnnotationScanner keeps references to application’s ClassLoader
>> (minor issue): https://issues.jboss.org/browse/AS7-3734
>>
>> javax.ws.rs.ext.FactoryFinder use application’s Class Loader which
>> causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735
>>
>> javax.el.BeanELResolver.properties keeps references to undeployed
>> classes: https://issues.jboss.org/browse/AS7-3736
>>
>> Threads ContextClassLoader leaks:
>>
>> AWT AppContext / EventQueue ClassLoader Memory Leaks:
>> https://issues.jboss.org/browse/AS7-3733
>>
>> sun.net.www.http.KeepAliveCache preventing classloader from being
>> garbage collected: https://issues.jboss.org/browse/AS7-3732
>>
>> Threads ContextClassLoader leak caused by EJB passivation pool:
>> https://issues.jboss.org/browse/AS7-3737
>>
>> ThreadLocal pseudo-leaks:
>>
>> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
>> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
>> "
>>
>> I have a fix for the JPA leak but not sure about the others.
>>
>> The ejb passivation pool leak probably needs the TCCL to be cleared when
>> new threads are created for the GroupAwareBackingCacheImpl.
>>
>> Scott
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Bill Burke
In reply to this post by Scott Marlow


On 2/13/12 12:59 PM, Scott Marlow wrote:
> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
> "
>

This may be Seam related.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Bill Burke
In reply to this post by Scott Marlow


On 2/13/12 12:59 PM, Scott Marlow wrote:
> javax.ws.rs.ext.FactoryFinder use application’s Class Loader which
> causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735
>

Are the JAX-RS API jars from resteasy being used?

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
On 02/14/2012 08:16 AM, Bill Burke wrote:
>
>
> On 2/13/12 12:59 PM, Scott Marlow wrote:
>> javax.ws.rs.ext.FactoryFinder use application’s Class Loader which
>> causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735
>>
>
> Are the JAX-RS API jars from resteasy being used?

Yes, AS 7.1 is using org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec
which came from resteasy (some details are in
https://issues.jboss.org/browse/JBEE-22) and sources are in
https://source.jboss.org/browse/JBossAS6/projects/specs/tags/jboss-jaxrs-api_1.1_spec-1.0.0.Final/src/main/java/javax/ws/rs/


>
> Bill
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
In reply to this post by Bill Burke
https://community.jboss.org/message/716191 is an AS7 user forum thread
about application classloader leaks in a few different areas.

All of them involve a Seam 2.2.2 application using Resteasy 2.3.1.  One
of the leaks is described in jira RESTEASY-660.

Is there something that the users application has to do, to get Seam
2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a
request?

Scott
-------- Original Message --------
Subject: Re: [jboss-as7-dev] help needed with responding to reported
classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation,
other)...
Date: Tue, 14 Feb 2012 07:33:29 -0500
From: Bill Burke <[hidden email]>
To: [hidden email]



On 2/13/12 12:59 PM, Scott Marlow wrote:
> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
> "
>

This may be Seam related.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Stuart Douglas

I'm pretty sure this is because the user is bundling their own rest easy jars in EAR/lib. The API caches stuff in statics, which is keeping a reference to the user deployed RESTeasy.

Stuart

On 15/02/2012, at 2:17 AM, Scott Marlow wrote:

> https://community.jboss.org/message/716191 is an AS7 user forum thread
> about application classloader leaks in a few different areas.
>
> All of them involve a Seam 2.2.2 application using Resteasy 2.3.1.  One
> of the leaks is described in jira RESTEASY-660.
>
> Is there something that the users application has to do, to get Seam
> 2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a
> request?
>
> Scott
> -------- Original Message --------
> Subject: Re: [jboss-as7-dev] help needed with responding to reported
> classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation,
> other)...
> Date: Tue, 14 Feb 2012 07:33:29 -0500
> From: Bill Burke <[hidden email]>
> To: [hidden email]
>
>
>
> On 2/13/12 12:59 PM, Scott Marlow wrote:
>> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
>> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
>> "
>>
>
> This may be Seam related.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> seam-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/seam-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
I agree that if the user doesn't bundle their own rest east jars, that
would probably work around the issue.

I haven't seen any standalone tests that recreate the leak yet but it
looks likely that the application copy of ResteasyBootstrap.java
(http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/resteasy/org/jboss/seam/resteasy/ResteasyBootstrap.java)
would call the API
ResteasyProviderFactory.setInstance(ResteasyProviderFactory factory)
which would save the static reference that doesn't get cleared.  Worse
than that, I think the setInstance call would blow away any other
ResteasyProviderFactory instance that is already set.

Which backs up the assertion that rest easy jars shouldn't be bundled
with a user app currently.  ResteasyBootstrap should probably clear the
instance at shutdown time but that wouldn't change the API static issue.

On 02/14/2012 03:06 PM, Stuart Douglas wrote:

>
> I'm pretty sure this is because the user is bundling their own rest easy jars in EAR/lib. The API caches stuff in statics, which is keeping a reference to the user deployed RESTeasy.
>
> Stuart
>
> On 15/02/2012, at 2:17 AM, Scott Marlow wrote:
>
>> https://community.jboss.org/message/716191 is an AS7 user forum thread
>> about application classloader leaks in a few different areas.
>>
>> All of them involve a Seam 2.2.2 application using Resteasy 2.3.1.  One
>> of the leaks is described in jira RESTEASY-660.
>>
>> Is there something that the users application has to do, to get Seam
>> 2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a
>> request?
>>
>> Scott
>> -------- Original Message --------
>> Subject: Re: [jboss-as7-dev] help needed with responding to reported
>> classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation,
>> other)...
>> Date: Tue, 14 Feb 2012 07:33:29 -0500
>> From: Bill Burke<[hidden email]>
>> To: [hidden email]
>>
>>
>>
>> On 2/13/12 12:59 PM, Scott Marlow wrote:
>>> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
>>> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
>>> "
>>>
>>
>> This may be Seam related.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> seam-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: [seam-dev] help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)...

Scott Marlow
How should the AS7 copy of the JAX-RS API jars be initialized?  It seems
wrong to me, that each deployed Seam application is calling
org.jboss.resteasy.spi.ResteasyProviderFactory.setInstance().

I also don't see why we need the
org.jboss.seam.resteasy.SeamResteasyProviderFactory class which just
passes through to the extended ResteasyProviderFactory class.

Short term fix #1:  eliminate the SeamResteasyProviderFactory class and
use ResteasyProviderFactory in its place.

Short term fix #2:  don't package the rest easy jars with the application.

I think with these changes, there may still be multiple calls to the
ResteasyProviderFactory.setInstance() but each one should pass the same
ResteasyProviderFactory (from the AS7 JAR-RS API jars).

To be worked out, changes to avoid having applications call
ResteasyProviderFactory.setInstance(), that should be initialized by AS7
(I think) or at least handled more gracefully.  As things stand
currently, applications probably shouldn't clear the instance (as that
would break other apps).

Thoughts?

Scott

On 02/14/2012 08:07 PM, Scott Marlow wrote:

> I agree that if the user doesn't bundle their own rest east jars, that
> would probably work around the issue.
>
> I haven't seen any standalone tests that recreate the leak yet but it
> looks likely that the application copy of ResteasyBootstrap.java
> (http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/resteasy/org/jboss/seam/resteasy/ResteasyBootstrap.java)
> would call the API
> ResteasyProviderFactory.setInstance(ResteasyProviderFactory factory)
> which would save the static reference that doesn't get cleared.  Worse
> than that, I think the setInstance call would blow away any other
> ResteasyProviderFactory instance that is already set.
>
> Which backs up the assertion that rest easy jars shouldn't be bundled
> with a user app currently.  ResteasyBootstrap should probably clear the
> instance at shutdown time but that wouldn't change the API static issue.
>
> On 02/14/2012 03:06 PM, Stuart Douglas wrote:
>>
>> I'm pretty sure this is because the user is bundling their own rest easy jars in EAR/lib. The API caches stuff in statics, which is keeping a reference to the user deployed RESTeasy.
>>
>> Stuart
>>
>> On 15/02/2012, at 2:17 AM, Scott Marlow wrote:
>>
>>> https://community.jboss.org/message/716191 is an AS7 user forum thread
>>> about application classloader leaks in a few different areas.
>>>
>>> All of them involve a Seam 2.2.2 application using Resteasy 2.3.1.  One
>>> of the leaks is described in jira RESTEASY-660.
>>>
>>> Is there something that the users application has to do, to get Seam
>>> 2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a
>>> request?
>>>
>>> Scott
>>> -------- Original Message --------
>>> Subject: Re: [jboss-as7-dev] help needed with responding to reported
>>> classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation,
>>> other)...
>>> Date: Tue, 14 Feb 2012 07:33:29 -0500
>>> From: Bill Burke<[hidden email]>
>>> To: [hidden email]
>>>
>>>
>>>
>>> On 2/13/12 12:59 PM, Scott Marlow wrote:
>>>> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak
>>>> on AS 7: https://issues.jboss.org/browse/RESTEASY-660
>>>> "
>>>>
>>>
>>> This may be Seam related.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> seam-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
> _______________________________________________
> seam-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/seam-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev