Andrew McDowell updated JBTM-444:
I had time to create a patch. This patch replaces the Hashtable with a TheadLocal to
store the timeout value. The (unified diff) patch works against trunk revision 24298,
and also against 4.2.3SP7. I have tested it live against a running system using
JProfiler, and the leak is no longer present. Also JTA transactions continue to maintain
their proper timeouts. I do not have a more comprehensive unit test for you, since this
is testing a memory side-effect instead of a direct action.
Slow memory leak in BaseTransaction
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: JTA Implementation
Affects Versions: 4.2.3.SP5, 4.2.3.SP6, 4.2.3.SP7
Environment: Windows XP and Solaris, Java 1.5.0_14, JBoss 4.2.2 (so with JBossTS
4.2.3_SP6, but the problem is still there in SP7)
Reporter: Andrew McDowell
We had JBossAS running for approximately 4 weeks under extremely heavy load, and
reached an OutOfMemory condition. Heap Dump analysis showed that the class
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction dominated 85% of the
In the class com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction, there is
a private Hashtable _timeouts, into which a thread id and a timeout value are placed when
transactions are started. However, the entries in the hashtable are never removed, even
if the thread dies. Given all the JBossAS invokers for EJBs create/destroy worker
threads, it means that client transactions can leak approximately 600 bytes (the String,
Integer and Hashtable$Entry).
The _timeouts table in our heap dump had some 6 million entries and a retained heap size
of over 1Gb.
Our workaround to the problem is that we are actively monitoring heap size and performing
rolling restarts when the heap space is too low.
You may want to consider using a ThreadLocal to store the timeout instead of a Hashtable,
which would accomplish the goal of storing the timeout value per thread, but would be
collected if the Thread died, but I will leave implementation speculation to you unless I
find the time to submit a patch.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: