cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Memory Leak at WSDLManagerImpl
Date Mon, 02 Jun 2008 11:43:28 GMT

On the client side, I specifically made sure the call to set the wsdl  
location on the factories did a "location = new String(location);"  
type thing to make sure the String is not an interned string.   Had to  
do that due to the strings being compiled directly in to the code and  
such.   It's quite possible that hasn't been done on the server side,  
but probably should.

It's good that you're doing this.   The way the "standalone" tck  
works, we don't hit these things.   We have that setup to create a new  
Bus (and thus new WSDLManagerImpl) for each of the deployed  
application.  Also, everything is deployed upfront at startup.   They  
aren't ever undeployed/redeployed.


On Jun 2, 2008, at 4:44 AM, Bharath Ganesh wrote:

> On a related note -
> There seems to be one more interesting issue here at  
> WSDLManagerImpl. The
> definitionsMap holds the WSDLDefinitions against a weak key, again  
> relying
> on the WeakHashMap semantics for removal.
> The loadDefinition(String) method loads the WSDLDef and puts this in  
> a map
> against a String key. But this String key, is a literal String and  
> will be
> present in the constant pool, where garbage collection never  
> happens. This
> would mean the key would always be referenced from the constant  
> pool, and
> the entry would never be removed:-(
> We shall fix this by always putting a URL as key in this map. The  
> only valid
> usage I saw was from WSDLServiceFactory. The WSDLServiceFactory,  
> instead of
> using the  wsdlManager.getDefinition(String) method, can create a  
> URL from
> this String, strongly refer the URL from wsdlURL field, and invoke the
> wsdlManager.getDefinition(URL) method.
> Any suggestions?
> On Sun, Jun 1, 2008 at 2:25 AM, Bharath Ganesh <>  
> wrote:
>> I figured out a memory leak at WSDLManagerImpl schemaCacheMap.
>> The schemaCacheMap here has a weak key - WSDLDefinition and value
>> ServiceSchemaInfo. A key,value pair is inserted into this map while  
>> building
>> a service. The entry is never explicitly removed from this map.  
>> Since the
>> map is a WeakHashMap, it is assumed that when the key  
>> WSDLDefinition is
>> weakly referenced, the entry would be removed from the map. But it  
>> is seen
>> that the value ServiceSchemaInfo(the value) holds on to a  
>> SchemaInfo which
>> in turn holds on to the ServiceInfo, which holds the WSDLDefinition  
>> through
>> the AbstractPropertiesHolder.
>> This would mean that the value of the CacheMap always strongly  
>> refers to
>> the key, which would mean the entry would never be removed from the  
>> map.
>> "*The value objects in a WeakHashMap are held by ordinary strong
>> references. Thus care should be taken to ensure that value objects  
>> do not
>> strongly refer to their own keys, either directly or indirectly,  
>> since that
>> will prevent the keys from being discarded"
>> *This would mean ServiceInfo, OperationInfo, BindingInfo,  
>> WSDLDefinition
>> would all stay in the VM even after the endpoint is stopped.
>> One solution I could think of was to explicitly remove the entry on
>> endpoint stop, instead of relying on the WeakHashMap semantics.   
>> This would
>> work fine for server endpoints. But Is there any way to do so for  
>> client
>> endpoints?

Daniel Kulp

View raw message