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

Andrew McDowell (JIRA) jira-events at lists.jboss.org
Fri Dec 5 14:11:49 EST 2008


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

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

          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)  (was: Windows XP and Solaris, Java 1.5.0_14)
    Affects Version/s: 4.2.3.SP6
                       4.2.3.SP5
          Description: 
 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.

  was:
 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 the 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.



> 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
>
>  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

        



More information about the jbossts-issues mailing list