[jbossts-issues] [JBoss JIRA] Updated: (JBTM-352) Memory leak in TransactionReaper._timeouts
[ http://jira.jboss.com/jira/browse/JBTM-352?page=all ]
Ivan Szanto updated JBTM-352:
-----------------------------
Attachment: TransactionReaper.java
This fixes the memory leak. Tested it by running ~ 100,000 transactions with good
results.
This is why I think it is a good starting point, but this is probably not the best way to
fix this problem, because it is both ugly and slow to use instanceof. I wrote it this way,
because there are 3 methods (remove, getTimeout and getRemainingTimeout) that pass the
hashtable key as an Object, therefore I was not sure if the only things I can recieve here
are Reapable and Uid objects.
Memory leak in TransactionReaper._timeouts
------------------------------------------
Key: JBTM-352
URL: http://jira.jboss.com/jira/browse/JBTM-352
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Transaction Core
Affects Versions: 4.3.0.GA
Environment: Compiled 4.3.0.GA for the EAP 4.3 as JTS according to the
instructions (by setting JBOSS_HOME to jboss-5.0.0.Beta4) on RHEL4.
Run ~ 1500 JMS transactions in EAP 4.3 all configuration on RHEL4 to see it leaks.
Used Sun jdk 1.5.0.14
Reporter: Ivan Szanto
Attachments: TransactionReaper.java
The leak can also be seen by using the debugger to check the number of entries in
TransactionReaper._timeouts after a couple of transactions.
It appears that the TransactionReaper.insert method uses ControlWrapper objects as keys
when putting elements into the hashtable, but the TransactionReaper.remove method
sometimes unsuccessfully tries to use Uid ojbects to remove them.
I will post a corrected version of TransactionReaper.java.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira