cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bharath Ganesh" <>
Subject Re: Memory Leak at WSDLManagerImpl
Date Mon, 02 Jun 2008 13:06:38 GMT
This has not been on the server side - The value of the wsdlLocation
attribute (from @WebService annotation) is passed down under to the
WSDLServiceFactory, which obviously will be a literal.

On Mon, Jun 2, 2008 at 5:13 PM, Daniel Kulp <> wrote:

> 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.
> Dan
> 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

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