Done, thanks for your help. En l'instant précis du 06/06/07 15:29, Rodrigo Ruiz s'exprimait en ces termes: > 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 >>>>> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
