Wow, you are right :-) You may want to open a bug case in JIRA.
It seems there will not be a next release of Axis 1, at least in short term, so probably the best workaround will be to download the source, modify the clearCache so it sets the ThreadLocal field to null, and compile it. Another way could be to set the field to null using reflection, instead of calling clearCache(). Regards, Rodrigo Rodrigo Ruiz wrote: > 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]
