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 Kulp <dk...@apache.org> on 2009/12/14 19:09:20 UTC
Re: Classloader leakage when using JAXB binding in appServer
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 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.
>