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 ax...@ws.apache.org on 2004/09/03 08:10:51 UTC
[jira] Closed: (AXIS-935) Using ThreadLocal Call objects in a servlet memory leak both on client and server side
Message:
The following issue has been closed.
Resolver: Davanum Srinivas
Date: Thu, 2 Sep 2004 11:08 PM
Used Rational Purify and checked for Axis specific leaks and found none.
-- dims
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/AXIS-935
Here is an overview of the issue:
---------------------------------------------------------------------
Key: AXIS-935
Summary: Using ThreadLocal Call objects in a servlet memory leak both on client and server side
Type: Bug
Status: Closed
Resolution: FIXED
Project: Axis
Components:
Basic Architecture
Versions:
1.1rc2
Assignee:
Reporter: Jennifer Jackson
Created: Mon, 30 Jun 2003 12:12 PM
Updated: Thu, 2 Sep 2004 11:08 PM
Environment: Operating System: All
Platform: All
Description:
I discovered using Axis in tomcat causes a memory leak.
It seems using threadlocal in the classes causes a memory leak for each Call
that is created. Threadlocal sticks around until the calling thread dies, and
since tomcat keeps threads alive to answer new calls, the threadlocal data
never goes away. The Call object gets stuck in the threadlocal data, which
contains the entire soap response and all objects. This is a BIG memory leak.
I initially cleared it by forcing all Call objects to clean their member vars
after I was done with a call, then I realized the source was from the thread
local class. Here is some info I found about threadlocal:
This is stated in the Sun Javadocs for ThreadLocal:
Each thread holds an implicit reference to its copy of a
ThreadLocal as long as the thread is alive and the
ThreadLocal object is accessible; after a thread goes
away, all of its copies of ThreadLocal variables are
subject to garbage collection (unless other references
to these copies exist).
So, this means that ANY APPLICATION that uses PreparedStatements in a thread
that 1) either does a lot of PreparedStatements or 2) never dies (i.e., a
main thread) will ALWAYS eventually have an out of memory error. Simply put,
this is a MEMORY LEAK. I imagine that the leak is very small, the
ThreadLocal object only contains one member variable, maybe 64 bytes or less
(depending on the VM implementation). So, our 60,000 PreparedStatements of 2
ThreadLocals each times 64 bytes (my wild guess) is 7.5MB.
Ideas? I've never used threadlocal myself so this is new to me.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira