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 Sun, 01 Jun 2008 01:49:57 GMT

Hmmm....   good sleuthing.

You definitely don't want to unregister it on endpoint stop or when  
done with the client.   The whole point of the cache is to hold onto  
it so it's reusable.  On popular thing to do is create a client, use  
it once, discard.  Create another client, use it once, discard.   
Etc...  The cache is to help that.

I think what might make some sense is to get rid of the schemaCacheMap  
entirely.   Change the definitionsMap to be a Map<Object, DefPair> map  
where DepPair holds a wsdldef and the schema.   Thus, the keys would  
be the same keys for the wsdl.

The put/set's would be more expensive as you would need to iterate  
through the cache to find the pair.  I doubt the map would be very big  
though so that may be acceptable.


On May 31, 2008, at 4:55 PM, 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