[jbossts-issues] [JBoss JIRA] Updated: (JBTM-444) Slow memory leak in BaseTransaction

[Andrew McDowell (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBTM-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew McDowell updated JBTM-444:
---------------------------------

    Attachment: JBTM-444.patch


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
> -----------------------------------
>
>                 Key: JBTM-444
>                 URL: https://jira.jboss.org/jira/browse/JBTM-444
>             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
>         Attachments: JBTM-444.patch
>
>
>  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 heap space.
> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira