Re: Memory Leak at WSDLManagerImpl

> 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
> key).
>
> 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
> expunging.
>
> Will commit these changes on 2.1 branch. DanK hope you will apply on  
> 2.0.7
> also.

>
>
>
> On Mon, Jun 2, 2008 at 11:55 AM, Bharath Ganesh <bharathganesh@...
> >
> wrote:
>
>
>> 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 <dkulp@...> 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
>>> dkulp@...
>>> http://www.dankulp.com/blog
>>>
>>>
>>>
>>>
>>>
>>