cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharath Ganesh" <bhar...@apache.org>
Subject Re: Memory Leak at WSDLManagerImpl
Date Mon, 02 Jun 2008 08:44:35 GMT
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 <bharath@apache.org> 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message