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 >> -- ------------------------------------------------------------------- GRID SYSTEMS, S.A. Rodrigo Ruiz Parc Bit - Edificio 17 Research Coordinator 07121 Palma de Mallorca Baleares - Spain http://www.gridsystems.com/ ------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
