Ivan Szanto updated JBTM-352:
Andrew, thanks for the feedback with lots of useful info!
I need a fix quickly, therefore I attach a new fix based on this information:
"The reason this is failing is because the comparison is being done the wrong way
round i.e. by calling Uid.equals(ControllWrapper) rather than
In this fix, if a Uid is supplied to TransactionReaper.remove, then it retrieves the
keyset from _timeouts, iterates over it and finds the Reapable that has the Uid supplied.
It then uses the Reapable it found to remove it from _timeouts.
It will probably cause performance problems if there are many items in _timeouts, but at
least it makes the memory leak go away (I tested it with the same test case as the
Do you think it's a valid fix?
Memory leak in TransactionReaper._timeouts
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 184.108.40.206
Reporter: Ivan Szanto
Assigned To: Andrew Dinn
Fix For: 4.4.CR1
Attachments: TransactionReaper.java, TransactionReaper.zip
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:
For more information on JIRA, see: http://www.atlassian.com/software/jira