Sorry, overlooked your line of code, i thought you mentioned to call
clearcache without mentioning where to locate it, sorry :)
It will not solve problem, however. If you see code below, calling
clearCache() will only reset the HashMap of *current* Thread. I need to
remove all cache of all Thread to avoid the leak. One way to do it is to
do cache = null; or cache = new ThreadLocal()
(ThreadLocal.ThreadLocalMap stored in Threads are referencing
ThreadLocals using WeakReferences, removing other reference to
ThreadLocal instance is engouh to ensure garbage collecting of content).
But i see no way to do this using the MethodCache interface.
//**
* Cache for Methods
* In fact this is a map (with classes as keys) of a map (with method-names
as keys)
*//
*transient* *private* *static* ThreadLocal cache;
*public* *void* clearCache() {
Map map = (Map) cache.get();
*if* (map != *null*) {
map.clear();
}
}
Btw, is there any reason to use a ThreadLocal for a cache?
Regards,
David Delbecq
En l'instant précis du 06/06/07 13:23, Rodrigo Ruiz s'exprimait en ces
termes:
> Hi,
>
> In both graphs, the call to MethodCache is made through the bean
> registry process. This is a part of the Axis client initialization
> consisting in finding out what is the mapping between java beans and
> their corresponding SOAP types.
>
> Finding a method within a class through Reflection is a slow process,
> and it is possible that Axis have to find the same method several times;
> for example, because the same bean is being mapped to more than one SOAP
> type. This is why a cache is being used.
>
> Said this, the MethodCache class is a "singleton". This means that only
> one instance is ever created, and it is always available through a call
> to MethodCache.getInstance().
>
> So, as I said before, you should call:
>
> MethodCache.getInstance().clearCache();
>
> to remove the contents of the map containing the offensive references.
> This must be enough to remove the leak.
>
> The best place to put this call is in a context listener (see
> ServletContextListener class in the servlet API), within its shutdown()
> method, which is called when the webapp is stopped.
>
>
> Hope this helps,
> Rodrigo
>
> David Delbecq wrote:
>
>> Hi,
>>
>> it's the classes references in cache that are keeping reference to their
>> class loader (accessible using getClass().getClassloader())
>>
>> Can somebody explain me what that cache does and what is the correct way
>> to clean it. The reason i ask this it because of the allocation graph
>> (see the two allocation graph of 2 offending entries in attachement). I
>> tracked where the 2 offending classes entries get stored inside that
>> cache and it looks like the two offending Map.Entry stored in this cache
>> are a direct result of org.apache.axis.client.Service static initializer
>> (that is, a static reference to this class triggers the creation of
>> entries inside the cache that then prevent correct garbage collecting).
>>
>> So, basically question is,
>>
>> What is, from caller's point of view, the exact complete call i need to
>> access this cache (so i can clear it)?
>>
>> Thank you.
>>
>>
>> En l'instant précis du 06/06/07 10:23, Rodrigo Ruiz s'exprimait en ces
>> termes:
>>
>>> Hi David,
>>>
>>> Looking at the code, I see no direct reference to the webapp classloader
>>> in the class MethodCache. The leaking references may be within the
>>> contents of the cache map, which can be cleared through the clearCache()
>>> method.
>>>
>>> Try to call MethodCache.getInstance().clearCache() from a context
>>> listener shutdown() method.
>>>
>>>
>>> Regards,
>>> Rodrigo Ruiz
>>>
>>> David Delbecq wrote:
>>>
>>>> Hello,
>>>> (cross-posting as i don't know if users can answer it or only dev have
>>>> needed inner knowledge)
>>>> Trying the whole day to locate a memoryleak in our webapplication i
>>>> finally narrowed it down to what seems an axis bug (see screenshots for
>>>> help)
>>>> Using heap walker of jprofiler after unloading webapplication, you can
>>>> see that a Thread (it's a tomcat http thread coming from a reuse thread
>>>> pool) is keeping a reference to a ThreadLocal that itself keeps a
>>>> reference to an axis class. (This is how Threadlocal works, it's the
>>>> Thread that keep the reference to prevent use of time consuming
>>>> 'synchronized' blocks when accessing value). The axis class itself owns
>>>> a references to it's webappclassloader, which, as a result, can't be
>>>> garbage collected and lots of memory (22M in this case) can't be freed.
>>>> You can see in allocation stack that this ThreadLocal was created inside
>>>> org/apache/axis/utils/cache/MethodCache
>>>> Looking at this class code
>>>>
>>>>
>>> (http://svn.apache.org/viewvc/webservices/axis/trunk/java/src/org/apache/axis/utils/cache/MethodCache.java?view=markup)
>>>
>>>> i see that there is no way, even by clearing cache, to empty the
>>>> ThreadLocal (as a reminder, the only way to remove reference from
>>>> current thread to threadlocal field is to call set(null) on it).
>>>> Now, i am not an expert at axis, all i have is a framework (shark) that
>>>> use axis as a support library. Maybe this framework is badly configured,
>>>> resulting in axis sing MethodCache which is not designed for web
>>>> environment, or maybe it's a bug in MethodCache. Before filling such bug
>>>> report, i'd like to be sure the use of MethodCache is not mentionned by
>>>> axis as to "not use in J2EE environments".
>>>> Any help appreciated.
>>>> David Delbecq
>>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
