[JBoss JIRA] (JBTM-789) XA connections leak when no modifier available
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-789?page=com.atlassian.jira.plugin.s... ]
Mark Little resolved JBTM-789.
------------------------------
Resolution: Done
> XA connections leak when no modifier available
> ----------------------------------------------
>
> Key: JBTM-789
> URL: https://issues.jboss.org/browse/JBTM-789
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Affects Versions: 4.11.0
> Environment: JBoss Transactions 4.11, Tomcat, Spring
> Reporter: Mauro Molinari
> Assignee: Mark Little
> Priority: Critical
> Fix For: 6.0.0.Final
>
> Attachments: Patch JBTM-789.txt
>
>
> I recently upgraded JBossTS from 4.6.1 GA to 4.11 Final. I see that bug JBTM-532 that I opened against 4.5 and 4.6 should have been fixed in 4.8.0. However, besides still having a null _theModifier when using PostgreSQL, the current (4.11) implementation of com.arjuna.ats.internal.jdbc.ConnectionImple.close() has a problem.
>
> I mean, if _theModifier is null, a comment says: "no indication about connections, so assume close immediately". However in this case only _theConnection (java.sql.Connection) is closed and set to null, while _recoveryConnection.closeCloseCurrentConnection() is not called, leading to an XAConnection leak.
> What I would expect is that if _theModifier is null, a log entry were added but nothing else were done; in particular I would expect not to return and let the following "if (!delayClose)" (towards the end of the method) close both the connections immediately.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-789) XA connections leak when no modifier available
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-789?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-789:
----------------------------------
I have applied a fix to the code in case anyone is using this before we use IronJacamar.
> XA connections leak when no modifier available
> ----------------------------------------------
>
> Key: JBTM-789
> URL: https://issues.jboss.org/browse/JBTM-789
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Affects Versions: 4.11.0
> Environment: JBoss Transactions 4.11, Tomcat, Spring
> Reporter: Mauro Molinari
> Assignee: Mark Little
> Priority: Critical
> Fix For: 6.0.0.Final
>
> Attachments: Patch JBTM-789.txt
>
>
> I recently upgraded JBossTS from 4.6.1 GA to 4.11 Final. I see that bug JBTM-532 that I opened against 4.5 and 4.6 should have been fixed in 4.8.0. However, besides still having a null _theModifier when using PostgreSQL, the current (4.11) implementation of com.arjuna.ats.internal.jdbc.ConnectionImple.close() has a problem.
>
> I mean, if _theModifier is null, a comment says: "no indication about connections, so assume close immediately". However in this case only _theConnection (java.sql.Connection) is closed and set to null, while _recoveryConnection.closeCloseCurrentConnection() is not called, leading to an XAConnection leak.
> What I would expect is that if _theModifier is null, a log entry were added but nothing else were done; in particular I would expect not to return and let the following "if (!delayClose)" (towards the end of the method) close both the connections immediately.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-789) XA connections leak when no modifier available
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-789?page=com.atlassian.jira.plugin.s... ]
Mark Little reassigned JBTM-789:
--------------------------------
Assignee: Mark Little (was: Tom Jenkinson)
> XA connections leak when no modifier available
> ----------------------------------------------
>
> Key: JBTM-789
> URL: https://issues.jboss.org/browse/JBTM-789
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Resource Manager
> Affects Versions: 4.11.0
> Environment: JBoss Transactions 4.11, Tomcat, Spring
> Reporter: Mauro Molinari
> Assignee: Mark Little
> Priority: Critical
> Fix For: 6.0.0.Final
>
> Attachments: Patch JBTM-789.txt
>
>
> I recently upgraded JBossTS from 4.6.1 GA to 4.11 Final. I see that bug JBTM-532 that I opened against 4.5 and 4.6 should have been fixed in 4.8.0. However, besides still having a null _theModifier when using PostgreSQL, the current (4.11) implementation of com.arjuna.ats.internal.jdbc.ConnectionImple.close() has a problem.
>
> I mean, if _theModifier is null, a comment says: "no indication about connections, so assume close immediately". However in this case only _theConnection (java.sql.Connection) is closed and set to null, while _recoveryConnection.closeCloseCurrentConnection() is not called, leading to an XAConnection leak.
> What I would expect is that if _theModifier is null, a log entry were added but nothing else were done; in particular I would expect not to return and let the following "if (!delayClose)" (towards the end of the method) close both the connections immediately.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1971) Cannot browse logs with the LogBrowser tool
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1971?page=com.atlassian.jira.plugin.... ]
Mark Little closed JBTM-1971.
-----------------------------
> Cannot browse logs with the LogBrowser tool
> -------------------------------------------
>
> Key: JBTM-1971
> URL: https://issues.jboss.org/browse/JBTM-1971
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tooling
> Affects Versions: 5.0.0.M5
> Reporter: Michael Musgrove
> Assignee: Mark Little
>
> I tried browsing some logs using the command:
> {noformat}
> java -Dcom.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.objectStoreDir=<path to logs> com.arjuna.ats.arjuna.tools.log.LogBrowser
> {noformat}
> This gives an interactive command line. I then had a go at listing some logs using:
> {noformat}
> -> select AtomicAction
> -> ls
> {noformat}
> The tool does not find any logs even though there are entries in the directory:
> {code}
> <path_ to_logs>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> {code}
> The problem is that the LogBrowser.listLogs operation uses the the type (AtomicAction) as the parameter to the call StoreManager.getRecoveryStore().allObjUids(type, buff)) but the actual type of an AtomicAction log is "/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1971) Cannot browse logs with the LogBrowser tool
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1971?page=com.atlassian.jira.plugin.... ]
Mark Little resolved JBTM-1971.
-------------------------------
Resolution: Done
> Cannot browse logs with the LogBrowser tool
> -------------------------------------------
>
> Key: JBTM-1971
> URL: https://issues.jboss.org/browse/JBTM-1971
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tooling
> Affects Versions: 5.0.0.M5
> Reporter: Michael Musgrove
> Assignee: Mark Little
>
> I tried browsing some logs using the command:
> {noformat}
> java -Dcom.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.objectStoreDir=<path to logs> com.arjuna.ats.arjuna.tools.log.LogBrowser
> {noformat}
> This gives an interactive command line. I then had a go at listing some logs using:
> {noformat}
> -> select AtomicAction
> -> ls
> {noformat}
> The tool does not find any logs even though there are entries in the directory:
> {code}
> <path_ to_logs>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> {code}
> The problem is that the LogBrowser.listLogs operation uses the the type (AtomicAction) as the parameter to the call StoreManager.getRecoveryStore().allObjUids(type, buff)) but the actual type of an AtomicAction log is "/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1971) Cannot browse logs with the LogBrowser tool
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1971?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1971:
-----------------------------------
Thanks Mike. Yes, that sounds like a good approach. Link the new JIRA to this one?
> Cannot browse logs with the LogBrowser tool
> -------------------------------------------
>
> Key: JBTM-1971
> URL: https://issues.jboss.org/browse/JBTM-1971
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tooling
> Affects Versions: 5.0.0.M5
> Reporter: Michael Musgrove
> Assignee: Mark Little
>
> I tried browsing some logs using the command:
> {noformat}
> java -Dcom.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.objectStoreDir=<path to logs> com.arjuna.ats.arjuna.tools.log.LogBrowser
> {noformat}
> This gives an interactive command line. I then had a go at listing some logs using:
> {noformat}
> -> select AtomicAction
> -> ls
> {noformat}
> The tool does not find any logs even though there are entries in the directory:
> {code}
> <path_ to_logs>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> {code}
> The problem is that the LogBrowser.listLogs operation uses the the type (AtomicAction) as the parameter to the call StoreManager.getRecoveryStore().allObjUids(type, buff)) but the actual type of an AtomicAction log is "/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1971) Cannot browse logs with the LogBrowser tool
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1971?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1971:
----------------------------------------
I have manually tested that the fix resolves the issue.
I have left the JIRA as unresolved since we need a test for it. Mark, do you want me to look into how to automate the testing of the tool, if so I think we can resolve the current issue and raise a new JIRA for that task?
> Cannot browse logs with the LogBrowser tool
> -------------------------------------------
>
> Key: JBTM-1971
> URL: https://issues.jboss.org/browse/JBTM-1971
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tooling
> Affects Versions: 5.0.0.M5
> Reporter: Michael Musgrove
> Assignee: Mark Little
>
> I tried browsing some logs using the command:
> {noformat}
> java -Dcom.arjuna.ats.arjuna.common.ObjectStoreEnvironmentBean.objectStoreDir=<path to logs> com.arjuna.ats.arjuna.tools.log.LogBrowser
> {noformat}
> This gives an interactive command line. I then had a go at listing some logs using:
> {noformat}
> -> select AtomicAction
> -> ls
> {noformat}
> The tool does not find any logs even though there are entries in the directory:
> {code}
> <path_ to_logs>/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> {code}
> The problem is that the LogBrowser.listLogs operation uses the the type (AtomicAction) as the parameter to the call StoreManager.getRecoveryStore().allObjUids(type, buff)) but the actual type of an AtomicAction log is "/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1976) Add support for JDBC object store on PostgreSQL Plus 9.2
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1976?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1976:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Add support for JDBC object store on PostgreSQL Plus 9.2
> --------------------------------------------------------
>
> Key: JBTM-1976
> URL: https://issues.jboss.org/browse/JBTM-1976
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Recovery
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.0.Final
>
>
> It is requested to add support for postgres plus which is distinct from postgres as a database. Dev do not have a postgres plus database to test on but as it is the commercial variant of postgres and matches version numbering it should be similar to the corresponding postgres variant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years