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:17:26 GMT
I have verified the GC with the below fix(schemaCacheMap has a weak value)
and the literal String fix(now always use the url at WSDLServiceFactory as

After an application undeployment, things look fine on the Java EE Server.
Except that the entry in JAXBCONTEXT_CACHE in JAXBDataBinding would be still
retained till the next endpoint deployment/undeployment - WeakHashMap
expunges stale entries only on map access. Thus the classloader and JAXB
classes of the undeployed application would still be on the heap till the
next app deployment. This is not a memory leak. Later we can think of a
daemon thread which will access this map periodically to force stale entry

Will commit these changes on 2.1 branch. DanK hope you will apply on 2.0.7

On Mon, Jun 2, 2008 at 11:55 AM, Bharath Ganesh <>

> Yes we would need to iterate through the map while putting/getting the
> ServiceSchemaInfo.
> Do you think we should instead choose to retain the schemaCacheMap, but
> make the value always a weak object. (Putting a WeakReference of the
> ServiceSchemaInfo in the map). This way also we can solve the current
> problem.
> What do you say?
> On Sun, Jun 1, 2008 at 7:19 AM, Daniel Kulp <> wrote:
>> 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.
>> Dan
>> 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

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