cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Feist <dfe...@gmail.com>
Subject Re: Classloader leakage when using JAXB binding in appServer
Date Mon, 18 Jan 2010 23:22:34 GMT
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 <dfeist@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.
> 


Mime
View raw message