You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by David Delbecq <de...@oma.be> on 2007/06/06 10:04:15 UTC
Big memory leak of axis in a web environment (ThreadLocal related)
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
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by David Delbecq <de...@oma.be>.
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by Rodrigo Ruiz <rr...@gridsystems.com>.
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by David Delbecq <de...@oma.be>.
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by Rodrigo Ruiz <rr...@gridsystems.com>.
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by David Delbecq <de...@oma.be>.
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: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Big memory leak of axis in a web environment (ThreadLocal related)
Posted by Rodrigo Ruiz <rr...@gridsystems.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
- --
- -------------------------------------------------------------------
GRID SYSTEMS, S.A. Rodrigo Ruiz
Parc Bit - Edificio 17 Research Coordinator
07121 Palma de Mallorca
Baleares - Spain
http://www.gridsystems.com/
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFGZm8Hp9m/F5UenDoRAqT3AKC54zU8C8aHrTdK0Wa33+hn31/O4wCgvkaz
nUSd58Tr1mpE/85dVqtltA8=
=tn4r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org