You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Feist <df...@gmail.com> on 2009/10/28 21:15:54 UTC
Classloader leakage when using JAXB binding in appServer
Hi,
I'm experiencing some class-loader leakage with a couple of cxf
classes and was wondering if anyone had seen this before or had any
ideas on possible solutions.
Scenario:
- Mule+CXF (all mule libs, all cxf libs and all dependencies) are
deployed as part of JCA .rar archive in Jboss. (It would be the same
with other appServers, or if libs are on the server class-path or a
sar/car etc. is used.)
- Therefore all CXF classes are loaded by a classloader that is parent
to webapp classloaders.
- Endpoints are configured and deployed using webapps, this is using
Mule but what occurs from the CXF perspective is that a
ServerFactoryBean, ServerFactory are Service are created and used.
- Endpoints are undeployed when webapp is undeployed. Cxf Service is
stopped etc.
- CXF version 2.1.5
Issue:
Even though everything that is no longer used gets garbage collected
without an issue ((Mule) CXFMessageReceiver and well as (CXF)
ServerFactory, Service etc.) classloader leakage is observed whereby a
WebappClassloader is created and never destroyed for each redeploy of
the same webapp!
Probable Causes:
- org.apache.cxf.common.util.ASMHelper.LOADER_MAP
This map continues to have reference to classes generated and used by
the now undeployed webapp meaning the webapp classloader never goes
away.
The implementation of this map although weak is not weak enough,
because if a entry references a key (it seems to) then the key
although it is a WeakReference never goes away and therefore neither
does the entry (the classloader).
See the "implementation note" 2/3 of the way through the javadoc here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html
- org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
Here is appears we have another map the maintains references to the
generated classes and in turn to the webappClassloader that is no more
expect this one doesn't even try to be weak. I notice there is a
clearCaches() method but i'm unsure about using that at anytime in
runtime because even though i'm taking down one cxf Service there may
be user services alive using jaxb at the same time.
I didn't file any jira issue(s) yet because I wanted to push it out on
the list first and see if there was anything I was missing or if this
is indeed a real issue.
thank!
Dan
Re: Classloader leakage when using JAXB binding in appServer
Posted by Daniel Kulp <dk...@apache.org>.
On Mon November 9 2009 2:02:27 pm Daniel Feist wrote:
> > Please file JIRA's and patches if at all possible. I'm actually
> > wondering if
> > some of your descriptions are the causes of:
> >
> > https://issues.apache.org/jira/browse/CXF-2286
> > https://issues.apache.org/jira/browse/CXF-1816
> >
> > If we can get your patches in, it would be good to recheck those to
> > see if
> > they are then fixed.
>
> Don't immediately seem related but may be.
>
> Whenever cxf is on server classpath and webapps use cxf any static
> instance variable in cxf classes can potentially cause issues with hot-
> deploy and pergen issues..
And, on windows, jar locking. On Windows, if the classloader referencing a
jar cannot be garbage collected, the jar cannot be deleted. I THINK that's
the cause of the above errors. (not 100% sure though)
> >>> Probable Causes:
> >>> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
> >>>
> >>> This map continues to have reference to classes generated and used
> >>> by the now undeployed webapp meaning the webapp classloader never
> >>> goes away.
> >>> The implementation of this map although weak is not weak enough,
> >>> because if a entry references a key (it seems to) then the key
> >>> although it is a WeakReference never goes away and therefore neither
> >>> does the entry (the classloader).
> >
> > OK. Makes sense.
>
> I have patch for this one, not test case though.
Super cool. :-) Please log a JIRA and attach.
> >>> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
> >>>
> >>> Here is appears we have another map the maintains references to the
> >>> generated classes and in turn to the webappClassloader that is no
> >>> more expect this one doesn't even try to be weak. I notice there is
> >>> a clearCaches() method but i'm unsure about using that at anytime in
> >>> runtime because even though i'm taking down one cxf Service there
> >>> may be user services alive using jaxb at the same time.
>
> Will do. No patch for this one yet, but if it's the same as the other
> issue above then should be pretty easier.
Yea. It might just be making the referecne to the JAXBContext a
WeakReference<JAXBContext> or similar. That may be enough to do it.
> If you have any thoughts on unit testing either of these then please
> let me know..
Oi. I have NO idea on that one short of writing several custom classloader
things and such, but that's probably more work than it's worth.
If you can get a test case, great. If not, at least get the patches up as
long as you've tested it in your environment. (and, of course, all our
existing tests pass)
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Classloader leakage when using JAXB binding in appServer
Posted by Daniel Feist <df...@gmail.com>.
> Please file JIRA's and patches if at all possible. I'm actually
> wondering if
> some of your descriptions are the causes of:
>
> https://issues.apache.org/jira/browse/CXF-2286
> https://issues.apache.org/jira/browse/CXF-1816
>
> If we can get your patches in, it would be good to recheck those to
> see if
> they are then fixed.
Don't immediately seem related but may be.
Whenever cxf is on server classpath and webapps use cxf any static
instance variable in cxf classes can potentially cause issues with hot-
deploy and pergen issues..
>>> Probable Causes:
>>> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
>>>
>>> This map continues to have reference to classes generated and used
>>> by the now undeployed webapp meaning the webapp classloader never
>>> goes away.
>>> The implementation of this map although weak is not weak enough,
>>> because if a entry references a key (it seems to) then the key
>>> although it is a WeakReference never goes away and therefore neither
>>> does the entry (the classloader).
>
> OK. Makes sense.
I have patch for this one, not test case though.
>
>>> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
>>>
>>> Here is appears we have another map the maintains references to the
>>> generated classes and in turn to the webappClassloader that is no
>>> more expect this one doesn't even try to be weak. I notice there is
>>> a clearCaches() method but i'm unsure about using that at anytime in
>>> runtime because even though i'm taking down one cxf Service there
>>> may be user services alive using jaxb at the same time.
>
> The clearCaches is just there for use in the unit tests where we
> want to make
> 100% sure the caches are cleared out before a test runs.
Ok, so i won't use this as a solution then it seems....
> Definitely check this with trunk and even the latest 2.1.x code on
> the 2.1.x
> branch. I believe the JAXBCONTEXT_CACHE stuff has gone through a
> couple
> iterations, just not exactly sure when each of the iterations
> occurred. It's
> currently using a CacheMap which does use weak keys, but the
> JAXBContext it
> holds in the value probalby holds the same Class objects and thus
> suffers the
> same problem as the ASM thing you mentioned. Patches would be
> good. :-)
Will do. No patch for this one yet, but if it's the same as the other
issue above then should be pretty easier.
If you have any thoughts on unit testing either of these then please
let me know..
thanks!
Dan
Re: Classloader leakage when using JAXB binding in appServer
Posted by Daniel Kulp <dk...@apache.org>.
On Mon November 9 2009 7:25:21 am Daniel Feist wrote:
> No thoughts on this one? I'll go ahead and file JIRA's then with
> patches... not sure about test cases though, have to think about to
> reproduce/test with unit test.
Please file JIRA's and patches if at all possible. I'm actually wondering if
some of your descriptions are the causes of:
https://issues.apache.org/jira/browse/CXF-2286
https://issues.apache.org/jira/browse/CXF-1816
If we can get your patches in, it would be good to recheck those to see if
they are then fixed.
> > Probable Causes:
> > - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
> >
> > This map continues to have reference to classes generated and used
> > by the now undeployed webapp meaning the webapp classloader never
> > goes away.
> > The implementation of this map although weak is not weak enough,
> > because if a entry references a key (it seems to) then the key
> > although it is a WeakReference never goes away and therefore neither
> > does the entry (the classloader).
OK. Makes sense.
> > - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
> >
> > Here is appears we have another map the maintains references to the
> > generated classes and in turn to the webappClassloader that is no
> > more expect this one doesn't even try to be weak. I notice there is
> > a clearCaches() method but i'm unsure about using that at anytime in
> > runtime because even though i'm taking down one cxf Service there
> > may be user services alive using jaxb at the same time.
The clearCaches is just there for use in the unit tests where we want to make
100% sure the caches are cleared out before a test runs.
Definitely check this with trunk and even the latest 2.1.x code on the 2.1.x
branch. I believe the JAXBCONTEXT_CACHE stuff has gone through a couple
iterations, just not exactly sure when each of the iterations occurred. It's
currently using a CacheMap which does use weak keys, but the JAXBContext it
holds in the value probalby holds the same Class objects and thus suffers the
same problem as the ASM thing you mentioned. Patches would be good. :-)
Dan
> > I didn't file any jira issue(s) yet because I wanted to push it out
> > on the list first and see if there was anything I was missing or if
> > this is indeed a real issue.
> >
> > thank!
> >
> > Dan
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Classloader leakage when using JAXB binding in appServer
Posted by Daniel Feist <df...@gmail.com>.
Dan,
See:
CXF-2624 (Classloader leakage in org.apache.cxf.common.util.ASMHelper.LOADER_MAP) -> Includes patch.
CXF-2625 (Classloader leakage in org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE) -> No patch.
sorry it's been a while,
Dan
On Dec 14, 2009, at 6:09 PM, Daniel Kulp wrote:
>
>
> Were JIRA's created for these? Are patches available?
>
> Just wanted to make sure this doesn't get lost.
>
> Thanks!
> Dan
>
>
>
> Daniel Feist wrote:
>>
>> No thoughts on this one? I'll go ahead and file JIRA's then with
>> patches... not sure about test cases though, have to think about to
>> reproduce/test with unit test.
>>
>> Dan
>>
>> Begin forwarded message:
>>
>>> From: Daniel Feist <df...@gmail.com>
>>> Date: October 28, 2009 6:15:54 PM GMT-02:00
>>> To: users@cxf.apache.org
>>> Subject: Classloader leakage when using JAXB binding in appServer
>>>
>>> Hi,
>>>
>>> I'm experiencing some class-loader leakage with a couple of cxf
>>> classes and was wondering if anyone had seen this before or had any
>>> ideas on possible solutions.
>>>
>>> Scenario:
>>>
>>> - Mule+CXF (all mule libs, all cxf libs and all dependencies) are
>>> deployed as part of JCA .rar archive in Jboss. (It would be the
>>> same with other appServers, or if libs are on the server class-path
>>> or a sar/car etc. is used.)
>>> - Therefore all CXF classes are loaded by a classloader that is
>>> parent to webapp classloaders.
>>> - Endpoints are configured and deployed using webapps, this is using
>>> Mule but what occurs from the CXF perspective is that a
>>> ServerFactoryBean, ServerFactory are Service are created and used.
>>> - Endpoints are undeployed when webapp is undeployed. Cxf Service
>>> is stopped etc.
>>> - CXF version 2.1.5
>>>
>>> Issue:
>>>
>>> Even though everything that is no longer used gets garbage collected
>>> without an issue ((Mule) CXFMessageReceiver and well as (CXF)
>>> ServerFactory, Service etc.) classloader leakage is observed whereby
>>> a WebappClassloader is created and never destroyed for each redeploy
>>> of the same webapp!
>>>
>>> Probable Causes:
>>>
>>> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
>>>
>>> This map continues to have reference to classes generated and used
>>> by the now undeployed webapp meaning the webapp classloader never
>>> goes away.
>>> The implementation of this map although weak is not weak enough,
>>> because if a entry references a key (it seems to) then the key
>>> although it is a WeakReference never goes away and therefore neither
>>> does the entry (the classloader).
>>>
>>> See the "implementation note" 2/3 of the way through the javadoc
>>> here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html
>>>
>>> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
>>>
>>> Here is appears we have another map the maintains references to the
>>> generated classes and in turn to the webappClassloader that is no
>>> more expect this one doesn't even try to be weak. I notice there is
>>> a clearCaches() method but i'm unsure about using that at anytime in
>>> runtime because even though i'm taking down one cxf Service there
>>> may be user services alive using jaxb at the same time.
>>>
>>> I didn't file any jira issue(s) yet because I wanted to push it out
>>> on the list first and see if there was anything I was missing or if
>>> this is indeed a real issue.
>>>
>>> thank!
>>>
>>> Dan
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Classloader-leakage-when-using-JAXB-binding-in-appServer-tp26101445p26779942.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: Classloader leakage when using JAXB binding in appServer
Posted by Daniel Kulp <dk...@apache.org>.
Were JIRA's created for these? Are patches available?
Just wanted to make sure this doesn't get lost.
Thanks!
Dan
Daniel Feist wrote:
>
> No thoughts on this one? I'll go ahead and file JIRA's then with
> patches... not sure about test cases though, have to think about to
> reproduce/test with unit test.
>
> Dan
>
> Begin forwarded message:
>
>> From: Daniel Feist <df...@gmail.com>
>> Date: October 28, 2009 6:15:54 PM GMT-02:00
>> To: users@cxf.apache.org
>> Subject: Classloader leakage when using JAXB binding in appServer
>>
>> Hi,
>>
>> I'm experiencing some class-loader leakage with a couple of cxf
>> classes and was wondering if anyone had seen this before or had any
>> ideas on possible solutions.
>>
>> Scenario:
>>
>> - Mule+CXF (all mule libs, all cxf libs and all dependencies) are
>> deployed as part of JCA .rar archive in Jboss. (It would be the
>> same with other appServers, or if libs are on the server class-path
>> or a sar/car etc. is used.)
>> - Therefore all CXF classes are loaded by a classloader that is
>> parent to webapp classloaders.
>> - Endpoints are configured and deployed using webapps, this is using
>> Mule but what occurs from the CXF perspective is that a
>> ServerFactoryBean, ServerFactory are Service are created and used.
>> - Endpoints are undeployed when webapp is undeployed. Cxf Service
>> is stopped etc.
>> - CXF version 2.1.5
>>
>> Issue:
>>
>> Even though everything that is no longer used gets garbage collected
>> without an issue ((Mule) CXFMessageReceiver and well as (CXF)
>> ServerFactory, Service etc.) classloader leakage is observed whereby
>> a WebappClassloader is created and never destroyed for each redeploy
>> of the same webapp!
>>
>> Probable Causes:
>>
>> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
>>
>> This map continues to have reference to classes generated and used
>> by the now undeployed webapp meaning the webapp classloader never
>> goes away.
>> The implementation of this map although weak is not weak enough,
>> because if a entry references a key (it seems to) then the key
>> although it is a WeakReference never goes away and therefore neither
>> does the entry (the classloader).
>>
>> See the "implementation note" 2/3 of the way through the javadoc
>> here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html
>>
>> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
>>
>> Here is appears we have another map the maintains references to the
>> generated classes and in turn to the webappClassloader that is no
>> more expect this one doesn't even try to be weak. I notice there is
>> a clearCaches() method but i'm unsure about using that at anytime in
>> runtime because even though i'm taking down one cxf Service there
>> may be user services alive using jaxb at the same time.
>>
>> I didn't file any jira issue(s) yet because I wanted to push it out
>> on the list first and see if there was anything I was missing or if
>> this is indeed a real issue.
>>
>> thank!
>>
>> Dan
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Classloader-leakage-when-using-JAXB-binding-in-appServer-tp26101445p26779942.html
Sent from the cxf-user mailing list archive at Nabble.com.
Classloader leakage when using JAXB binding in appServer
Posted by Daniel Feist <df...@gmail.com>.
No thoughts on this one? I'll go ahead and file JIRA's then with
patches... not sure about test cases though, have to think about to
reproduce/test with unit test.
Dan
Begin forwarded message:
> From: Daniel Feist <df...@gmail.com>
> Date: October 28, 2009 6:15:54 PM GMT-02:00
> To: users@cxf.apache.org
> Subject: Classloader leakage when using JAXB binding in appServer
>
> Hi,
>
> I'm experiencing some class-loader leakage with a couple of cxf
> classes and was wondering if anyone had seen this before or had any
> ideas on possible solutions.
>
> Scenario:
>
> - Mule+CXF (all mule libs, all cxf libs and all dependencies) are
> deployed as part of JCA .rar archive in Jboss. (It would be the
> same with other appServers, or if libs are on the server class-path
> or a sar/car etc. is used.)
> - Therefore all CXF classes are loaded by a classloader that is
> parent to webapp classloaders.
> - Endpoints are configured and deployed using webapps, this is using
> Mule but what occurs from the CXF perspective is that a
> ServerFactoryBean, ServerFactory are Service are created and used.
> - Endpoints are undeployed when webapp is undeployed. Cxf Service
> is stopped etc.
> - CXF version 2.1.5
>
> Issue:
>
> Even though everything that is no longer used gets garbage collected
> without an issue ((Mule) CXFMessageReceiver and well as (CXF)
> ServerFactory, Service etc.) classloader leakage is observed whereby
> a WebappClassloader is created and never destroyed for each redeploy
> of the same webapp!
>
> Probable Causes:
>
> - org.apache.cxf.common.util.ASMHelper.LOADER_MAP
>
> This map continues to have reference to classes generated and used
> by the now undeployed webapp meaning the webapp classloader never
> goes away.
> The implementation of this map although weak is not weak enough,
> because if a entry references a key (it seems to) then the key
> although it is a WeakReference never goes away and therefore neither
> does the entry (the classloader).
>
> See the "implementation note" 2/3 of the way through the javadoc
> here: http://java.sun.com/j2se/1.5.0/docs/api/java/util/WeakHashMap.html
>
> - org.apache.cxf.jaxb.JAXBDataBinding.JAXBCONTEXT_CACHE
>
> Here is appears we have another map the maintains references to the
> generated classes and in turn to the webappClassloader that is no
> more expect this one doesn't even try to be weak. I notice there is
> a clearCaches() method but i'm unsure about using that at anytime in
> runtime because even though i'm taking down one cxf Service there
> may be user services alive using jaxb at the same time.
>
> I didn't file any jira issue(s) yet because I wanted to push it out
> on the list first and see if there was anything I was missing or if
> this is indeed a real issue.
>
> thank!
>
> Dan
>
>