[ http://jira.jboss.com/jira/browse/JBTM-327?page=all ] Mark Little updated JBTM-327: ----------------------------- Component/s: WS-T Implementation -- 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

[ https://jira.jboss.org/jira/browse/JBTM-327?page=com.atlassian.jira.plugi... ] Brice Ruth updated JBTM-327: ---------------------------- Attachment: JBTM-327_patch.txt Per Red Hat Support Case 263468, attaching proposed patch to fix memory leak for InboundBridge and Xids in TxBridgeManager. +Needs review to determine if changes to BridgeParticipantAT are calling removeMappings() at the appropriate time and if this covers all the necessary cleanup cases. +Recommendation: would it be beneficial to make the entries in the concurrent hashmaps "weak" references, in case any border condition fails to remove a mapping? Or would this only work if a WeakHashMap were used (which isn't available in a Concurrent flavor until possibly Java 7)? -- 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

[ https://jira.jboss.org/jira/browse/JBTM-327?page=com.atlassian.jira.plugi... ] Jonathan Halliday commented on JBTM-327: ---------------------------------------- Due to the async messaging and timeouts, it's possible you'll wind up in a situation where an attempt is made to remove an entry that has already been removed. In such case removeMappings() should log.warn or fail silent rather than throwing NullPointerException. In future releases this will also apply to crash recovery situations, in which the mapping won't exist as it's not persisted. WeakRefs can cause GC issues in high load situations, so in general I prefer to avoid them even in situations where concurrency control is not an issue. Best alternative for the paranoid would be a Timer that looked for mappings that outlived the expected tx timeout by some safety interval. Its also feasible to have the bridge expose a 'purge mappings' method by JMX to allow manual cleanup without a need to restart the server. -- 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

[ https://jira.jboss.org/jira/browse/JBTM-327?page=com.atlassian.jira.plugi... ] Jonathan Halliday reassigned JBTM-327: -------------------------------------- Assignee: Jonathan Halliday -- 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