From issues at jboss.org Thu Jun 1 04:53:00 2017 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 1 Jun 2017 04:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2902: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 5 03:22:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Jun 2017 03:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2902: -------------------------------- Fix Version/s: 5.next > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 5 03:23:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Jun 2017 03:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2901) XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2901: -------------------------------- Fix Version/s: 5.next > XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES > ------------------------------------------------------------------------------------- > > Key: JBTM-2901 > URL: https://issues.jboss.org/browse/JBTM-2901 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 5 03:24:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Jun 2017 03:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2901) XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2901: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Hi Mike, I marked as resolved as you merged the PR. Feel free to re-open if necessary. > XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES > ------------------------------------------------------------------------------------- > > Key: JBTM-2901 > URL: https://issues.jboss.org/browse/JBTM-2901 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 5 13:07:00 2017 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 5 Jun 2017 13:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris moved SB-91 to JBTM-2903: ----------------------------------------- Project: JBoss Transaction Manager (was: Spring Boot & Cloud) Key: JBTM-2903 (was: SB-91) > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 5 13:09:00 2017 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 5 Jun 2017 13:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1185 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 06:49:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Jun 2017 06:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416808#comment-13416808 ] Tom Jenkinson commented on JBTM-2903: ------------------------------------- Please can you add a stack trace showing the commit call failing? I am wondering when commit comes after ENDRSCAN. > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 6 15:36:00 2017 From: issues at jboss.org (Andy Wilkinson (JIRA)) Date: Tue, 6 Jun 2017 15:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2904) ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties In-Reply-To: References: Message-ID: Andy Wilkinson created JBTM-2904: ------------------------------------ Summary: ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties Key: JBTM-2904 URL: https://issues.jboss.org/browse/JBTM-2904 Project: JBoss Transaction Manager Issue Type: Bug Affects Versions: 5.5.7.Final Reporter: Andy Wilkinson I believe that [this commit|https://github.com/jbosstm/narayana/commit/789a02b78c8ffe5a7a079604e9ba712287cdf7d1] has introduced a regression in how {{ConnectionManager}} handles credentials. Previously, if the {{Properties}} contained an {{XADataSource}} and no credentials, the data source's default credentials would be used, i.e. {{XADataSource.getXAConnection()}} would be called by {{ProvidedXADataSourceConnection}}. With the aforelinked change, {{ConnectionManager}} now coerces {{null}} credentials to empty strings. As a result {{XADataSource.getXAConnection(String, String)}} is called by {{ProvidedXADataSourceConnection}} with the empty credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 04:23:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 04:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2904) ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2904. --------------------------------- Resolution: Duplicate Issue [~awilkinson] - should be fixed (as of very recently) here: JBTM-2902, if not, please do re-open > ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2904 > URL: https://issues.jboss.org/browse/JBTM-2904 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.5.7.Final > Reporter: Andy Wilkinson > > I believe that [this commit|https://github.com/jbosstm/narayana/commit/789a02b78c8ffe5a7a079604e9ba712287cdf7d1] has introduced a regression in how {{ConnectionManager}} handles credentials. Previously, if the {{Properties}} contained an {{XADataSource}} and no credentials, the data source's default credentials would be used, i.e. {{XADataSource.getXAConnection()}} would be called by {{ProvidedXADataSourceConnection}}. With the aforelinked change, {{ConnectionManager}} now coerces {{null}} credentials to empty strings. As a result {{XADataSource.getXAConnection(String, String)}} is called by {{ProvidedXADataSourceConnection}} with the empty credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 04:27:00 2017 From: issues at jboss.org (Andy Wilkinson (JIRA)) Date: Wed, 7 Jun 2017 04:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2904) ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417476#comment-13417476 ] Andy Wilkinson commented on JBTM-2904: -------------------------------------- Thank you, and apologies for not spotting the original issue. > ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2904 > URL: https://issues.jboss.org/browse/JBTM-2904 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.5.7.Final > Reporter: Andy Wilkinson > > I believe that [this commit|https://github.com/jbosstm/narayana/commit/789a02b78c8ffe5a7a079604e9ba712287cdf7d1] has introduced a regression in how {{ConnectionManager}} handles credentials. Previously, if the {{Properties}} contained an {{XADataSource}} and no credentials, the data source's default credentials would be used, i.e. {{XADataSource.getXAConnection()}} would be called by {{ProvidedXADataSourceConnection}}. With the aforelinked change, {{ConnectionManager}} now coerces {{null}} credentials to empty strings. As a result {{XADataSource.getXAConnection(String, String)}} is called by {{ProvidedXADataSourceConnection}} with the empty credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2904) ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417567#comment-13417567 ] Tom Jenkinson commented on JBTM-2904: ------------------------------------- No problem - thanks for providing a link to the Spring Boot report > ConnectionManager no longer uses the underlying XADataSource's credentials when none are provided in its Properties > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2904 > URL: https://issues.jboss.org/browse/JBTM-2904 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.5.7.Final > Reporter: Andy Wilkinson > > I believe that [this commit|https://github.com/jbosstm/narayana/commit/789a02b78c8ffe5a7a079604e9ba712287cdf7d1] has introduced a regression in how {{ConnectionManager}} handles credentials. Previously, if the {{Properties}} contained an {{XADataSource}} and no credentials, the data source's default credentials would be used, i.e. {{XADataSource.getXAConnection()}} would be called by {{ProvidedXADataSourceConnection}}. With the aforelinked change, {{ConnectionManager}} now coerces {{null}} credentials to empty strings. As a result {{XADataSource.getXAConnection(String, String)}} is called by {{ProvidedXADataSourceConnection}} with the empty credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2902) Transactional driver connections do not handle empty credentials correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2902. ------------------------------- > Transactional driver connections do not handle empty credentials correctly > -------------------------------------------------------------------------- > > Key: JBTM-2902 > URL: https://issues.jboss.org/browse/JBTM-2902 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.6.1.Final > > > Transactional driver connections only check for null credentials. If they are empty strings they are used as actual username and password, which is incorrect. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2901) XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2901. ------------------------------- > XARecoveryModule second pass shouldn't be executed if the state is not BETWEEN_PASSES > ------------------------------------------------------------------------------------- > > Key: JBTM-2901 > URL: https://issues.jboss.org/browse/JBTM-2901 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.6.1.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2873) WildFly to GlassFish interop: check that recovery works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2873: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > WildFly to GlassFish interop: check that recovery works > ------------------------------------------------------- > > Key: JBTM-2873 > URL: https://issues.jboss.org/browse/JBTM-2873 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS > Affects Versions: 5.5.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Check interoperability between WildFly and GlassFish. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 7 06:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 7 Jun 2017 06:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.6.1.Final) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 8 07:27:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 8 Jun 2017 07:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2905: ------------------------------------- Summary: JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling Key: JBTM-2905 URL: https://issues.jboss.org/browse/JBTM-2905 Project: JBoss Transaction Manager Issue Type: Bug Components: Tooling Affects Versions: 5.6.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. {code} INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] {code} The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 8 07:31:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 8 Jun 2017 07:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1186 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 02:44:01 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 12 Jun 2017 02:44:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1820) Integrate with Camel to support XA Transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #199 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Integrate with Camel to support XA Transaction > ---------------------------------------------- > > Key: JBTM-1820 > URL: https://issues.jboss.org/browse/JBTM-1820 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.later > > > From Ning Jiang (njiang at redhat.com) > {quote} > Camel is using Spring TransactionTemplates to implement the Transactional Client pattern[1]. > As the Spring PlatformTransactionManager cannot manage the multiple resources, we are using the atomikos to show the user how to manage the transactions between JMS and DB resource. It could great if we can replace the atomikos with narayana, then we can promote this example as reference to SA who can sale the solution to the customer. > Another interesting task could be using the narayana JTA wrapper classes to replace the Spring TransactionTemplate in Camel. As we don't want to build out products on top of Spring framework, using narayana could help us to get ride of Spring and introduce the narayana to integration customer. > [1]http://camel.apache.org/transactional-client.html > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 06:00:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 12 Jun 2017 06:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2122: ----------------------------------- Assignee: Amos Feng (was: Michael Musgrove) > Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2122 > URL: https://issues.jboss.org/browse/JBTM-2122 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 06:00:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 12 Jun 2017 06:00:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419336#comment-13419336 ] Tom Jenkinson commented on JBTM-2122: ------------------------------------- It would be useful to look at CosTransactions.idl to see what facilities are available in JTS and check which are available in the EJB remoting transport > Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2122 > URL: https://issues.jboss.org/browse/JBTM-2122 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 10:10:00 2017 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 12 Jun 2017 10:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2903: ---------------------------------- Description: Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. {code} 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED in flight is false 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- java.lang.IllegalStateException: Connection has not been opened at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: java.lang.NullPointerException: null at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off {code} was:Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 12 10:16:01 2017 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 12 Jun 2017 10:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419621#comment-13419621 ] Gytis Trikleris commented on JBTM-2903: --------------------------------------- Commit comes after ENDRSCAN in a following scenario: # AtomicActionRecoveryModule recovers XAResourceRecord # XAResourceRecord calls XARecoveryModule.getNewXAResource # It calls periodicWorkFirstPass(ScanStates.IDLE) # Because of the provided state ENDRSCAN is executed here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java#L199 # AtomicActionRecoveryModule commits the transaction > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 01:26:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 13 Jun 2017 01:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2870) Provide way of getting suppressed exceptions out of SubordinateTransaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419918#comment-13419918 ] RH Bugzilla Integration commented on JBTM-2870: ----------------------------------------------- Ji?? B?lek changed the Status of [bug 1435549|https://bugzilla.redhat.com/show_bug.cgi?id=1435549] from ON_QA to VERIFIED > Provide way of getting suppressed exceptions out of SubordinateTransaction > -------------------------------------------------------------------------- > > Key: JBTM-2870 > URL: https://issues.jboss.org/browse/JBTM-2870 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Affects Versions: 4.17.38, 5.5.5.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 4.17.40, 5.2.23.Final, 5.5.7.Final, 5.6.0.Final > > > We need to provide way how to pass suppressed exceptions of of the `SubordinateTransaction` to the caller. > This request came from customer case and https://bugzilla.redhat.com/show_bug.cgi?id=1435549 as we need to provide exceptions thrown from transaction resource. > The interface is used for controlling propagated transaction from one server to another in EAP/WFLY. > Callers are is ejb3 subsystem in EAP 6.4/7.0 and WFTC in EAP 7.1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 08:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Jun 2017 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2903: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 08:50:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Jun 2017 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2903: -------------------------------- Fix Version/s: 5.next > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 09:16:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 13 Jun 2017 09:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2906) It's not psossible to combine start and end flags in call of XATerminator.recover In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2906: ------------------------------------- Summary: It's not psossible to combine start and end flags in call of XATerminator.recover Key: JBTM-2906 URL: https://issues.jboss.org/browse/JBTM-2906 Project: JBoss Transaction Manager Issue Type: Bug Components: JCA Affects Versions: 5.6.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor Current implementation of {{XATerminator.recover}} (either for JTA or JTS) does not permit combining flags to use. https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L323 https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L246 Flags are expected to be combined as their values are designed to use bitwise operators. Especially {{|}} is handy for starting and ending the recover scan in once. Currently we need to call {code} XATerminator.recover(XAResource.TMSTARTRSCAN); XATerminator.recover(XAResource.TMENDRSCAN); {code} Values are {code} XAResource.TMSTARTRSCAN : 16777216 : 1000000000000000000000000 XAResource.TMENDRSCAN : 8388608 : 100000000000000000000000 {code} The way would be ability to call the {{recover}} like this {code} XATerminator.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 09:17:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 13 Jun 2017 09:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2906) It's not possible to combine start and end flags in call of XATerminator.recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2906: ---------------------------------- Summary: It's not possible to combine start and end flags in call of XATerminator.recover (was: It's not psossible to combine start and end flags in call of XATerminator.recover ) > It's not possible to combine start and end flags in call of XATerminator.recover > --------------------------------------------------------------------------------- > > Key: JBTM-2906 > URL: https://issues.jboss.org/browse/JBTM-2906 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Current implementation of {{XATerminator.recover}} (either for JTA or JTS) does not permit combining flags to use. > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L323 > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L246 > Flags are expected to be combined as their values are designed to use bitwise operators. Especially {{|}} is handy for starting and ending the recover scan in once. > Currently we need to call > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN); > XATerminator.recover(XAResource.TMENDRSCAN); > {code} > Values are > {code} > XAResource.TMSTARTRSCAN : 16777216 : 1000000000000000000000000 > XAResource.TMENDRSCAN : 8388608 : 100000000000000000000000 > {code} > The way would be ability to call the {{recover}} like this > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 13 09:51:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Jun 2017 09:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2906) It's not possible to combine start and end flags in call of XATerminator.recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420615#comment-13420615 ] Tom Jenkinson commented on JBTM-2906: ------------------------------------- It might be nice and I see your point but: https://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int- Described as "One of" However the XA spec does allow it: "TMENDRSCAN This flag indicates that xa_recover() should end the recovery scan after returning the XIDs. If this flag is used in conjunction with TMSTARTRSCAN, the single xa_recover() call starts and then ends a scan." So let's go with allowing it. > It's not possible to combine start and end flags in call of XATerminator.recover > --------------------------------------------------------------------------------- > > Key: JBTM-2906 > URL: https://issues.jboss.org/browse/JBTM-2906 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Current implementation of {{XATerminator.recover}} (either for JTA or JTS) does not permit combining flags to use. > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L323 > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L246 > Flags are expected to be combined as their values are designed to use bitwise operators. Especially {{|}} is handy for starting and ending the recover scan in once. > Currently we need to call > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN); > XATerminator.recover(XAResource.TMENDRSCAN); > {code} > Values are > {code} > XAResource.TMSTARTRSCAN : 16777216 : 1000000000000000000000000 > XAResource.TMENDRSCAN : 8388608 : 100000000000000000000000 > {code} > The way would be ability to call the {{recover}} like this > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 15 09:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Jun 2017 09:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka moved JBEAP-11580 to JBTM-2907: ----------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2907 (was: JBEAP-11580) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTS (was: Transactions) Affects Version/s: 5.5.24.Final 5.6.1.Final (was: 7.1.0.ER1) > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.5.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 15 09:22:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Jun 2017 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421810#comment-13421810 ] Ondra Chaloupka commented on JBTM-2907: --------------------------------------- per discussion with David and Tom the way of fixing JBEAP-11528 is to implement {{doRecover}} in JTS XATerminatorImple. The {{XATerminator.recover}} call from RAR is then provided to call {{doRecover(null,null}} which returns all subordinate in-doubt transactions which is expected. > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 15 09:34:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 15 Jun 2017 09:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1187 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:41:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 04:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2905: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:52:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Fix Version/s: 5.next > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:56:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2907: -------------------------------- Fix Version/s: 5.next > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.next > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2907: -------------------------------- Fix Version/s: 5.2.25.Final > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.next > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:57:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Fix Version/s: 5.5.24.Final > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next, 5.5.24.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:58:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Fix Version/s: 5.2.25.Final (was: 5.5.24.Final) > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.2.25.Final, 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 04:59:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Jun 2017 04:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2905: --------------------------------- Just for backport to 5.5 > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.2.25.Final, 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 05:57:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 05:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422203#comment-13422203 ] Ondra Chaloupka edited comment on JBTM-2905 at 6/16/17 5:56 AM: ---------------------------------------------------------------- [~mmusgrov] ok, that could be my wrong in understanding the issue here. Without the header reader I got troubles to get working ExpiredAssumedCompleteScanner. But I could take it from a wrong end. In that case, this change would be superfluous and the fix should go in opposite way - removing from the default list and leaving header reader in the test package. Can you please elaborate a bit on what is the correct way of fixing it? Thanks in advance! was (Author: ochaloup): [~mmusgrov] ok, that could be my wrong in understanding the issue here. Without the header reader I got troubles to get working ExpiredAssumedCompleteScanner. But I could take it from a wrong end. In that case, this change would be superfluous and the fix should go in opposite way - removing from the default list and leaving header reader in the test package. Can you please elaborate a bit on it what is the correct way of fixing it? Thanks in advance! > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.2.25.Final, 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 06:20:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 06:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka moved JBEAP-11609 to JBTM-2908: ----------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2908 (was: JBEAP-11609) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTS (was: Transactions) Affects Version/s: 5.6.1.Final 5.5.24.Final (was: 7.1.0.DR18) > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 06:29:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 06:29:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1192 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 06:35:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 06:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13422234#comment-13422234 ] Ondra Chaloupka commented on JBTM-2905: --------------------------------------- [~tomjenkinson] there was not directly linked JBEAP issue to this. Maybe one could be created. It was found during my investigation and the main issue here was the error message {{ARJUNA012389: OSB: Error constructing record header}} during container startup. The reason why that was linked to the JBEAP was that my understanding of not having the header reader available was the fact of having trouble to get working the expired scanner. That was how I understand the functionality. But I can be missing something. > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.2.25.Final, 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 16 09:26:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 16 Jun 2017 09:26:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2907: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.next > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 20 15:42:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 20 Jun 2017 15:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2909) Use interposed sync for Transactional Driver close connection call In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2909: ----------------------------------- Summary: Use interposed sync for Transactional Driver close connection call Key: JBTM-2909 URL: https://issues.jboss.org/browse/JBTM-2909 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next HHH registers as an interposed sync so we need to so we can close after it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 20 16:45:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 20 Jun 2017 16:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2910: ----------------------------------- Summary: Don't allow transactional driver recovery handler to close underlying JDBC connection Key: JBTM-2910 URL: https://issues.jboss.org/browse/JBTM-2910 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next As the reference is not stored the transactionaldriver recovery connection is eligible for finalizer which calls the connection close and prevents recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 04:34:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 04:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2910: -------------------------------- Description: As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and prevents recovery from completing. (was: As the reference is not stored the transactionaldriver recovery connection is eligible for finalizer which calls the connection close and prevents recovery from completing.) > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and prevents recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 04:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 04:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2910: -------------------------------- Description: As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. (was: As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and prevents recovery from completing.) > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 07:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 07:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2911: ----------------------------------- Summary: Allow BasicXARecovery to be rescanned by periodic recovery Key: JBTM-2911 URL: https://issues.jboss.org/browse/JBTM-2911 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Tom Jenkinson Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2905. --------------------------------- Resolution: Done > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.2.25.Final, 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:20:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:20:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2908: -------------------------------- Fix Version/s: 5.next > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2908: -------------------------------- Fix Version/s: 5.2.25.Final > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.next > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:22:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Fix Version/s: (was: 5.2.25.Final) > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:22:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424689#comment-13424689 ] Tom Jenkinson commented on JBTM-2905: ------------------------------------- I will revert it from 5.5.25 as there is no JBEAP. > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:29:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2909) Use interposed sync for Transactional Driver close connection call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2909: -------------------------------- Component/s: Transactional Driver > Use interposed sync for Transactional Driver close connection call > ------------------------------------------------------------------ > > Key: JBTM-2909 > URL: https://issues.jboss.org/browse/JBTM-2909 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > HHH registers as an interposed sync so we need to so we can close after it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:29:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2910: -------------------------------- Component/s: Transactional Driver > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:29:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2911: -------------------------------- Component/s: Transactional Driver > Allow BasicXARecovery to be rescanned by periodic recovery > ---------------------------------------------------------- > > Key: JBTM-2911 > URL: https://issues.jboss.org/browse/JBTM-2911 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:29:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2911: -------------------------------- Fix Version/s: 5.next > Allow BasicXARecovery to be rescanned by periodic recovery > ---------------------------------------------------------- > > Key: JBTM-2911 > URL: https://issues.jboss.org/browse/JBTM-2911 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2909) Use interposed sync for Transactional Driver close connection call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2909: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1193 > Use interposed sync for Transactional Driver close connection call > ------------------------------------------------------------------ > > Key: JBTM-2909 > URL: https://issues.jboss.org/browse/JBTM-2909 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > HHH registers as an interposed sync so we need to so we can close after it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2910: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1193 > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2911: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1193 > Allow BasicXARecovery to be rescanned by periodic recovery > ---------------------------------------------------------- > > Key: JBTM-2911 > URL: https://issues.jboss.org/browse/JBTM-2911 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 09:30:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 09:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2908: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.6.1.Final, 5.5.24.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.next > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:11:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2907: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:11:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2903: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.6.2.Final > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:12:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2908: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.6.2.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:12:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.6.2.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:13:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2905. ------------------------------- > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.6.2.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:13:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2903) Improve JMS integration to be able to control connections more smartly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2903. ------------------------------- > Improve JMS integration to be able to control connections more smartly > ---------------------------------------------------------------------- > > Key: JBTM-2903 > URL: https://issues.jboss.org/browse/JBTM-2903 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.6.2.Final > > > Currently JMS integration opens a connection on getXAResources call and closes it on TMENDSCAN call. With a latest changes to XARecoveryModule, this connection management doesn't work any more, because connection might be closed before the commit call and result in a failure. > {code} > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Periodic recovery second pass at Mon, 29 May 2017 08:38:35 > 2017-05-29 08:38:35.000 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AtomicActionRecoveryModule second pass > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.008 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.041 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffac110004:857c:592bddb6:b > ActionStatus is ActionStatus.COMMITTED in flight is false > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:ffffac110004:857c:592bddb6:b ) > 2017-05-29 08:38:35.047 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::BasicAction(0:ffffac110004:857c:592bddb6:b) > 2017-05-29 08:38:35.048 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::activate() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.058 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState(0:ffffac110004:857c:592bddb6:b, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.059 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::restore_state () > 2017-05-29 08:38:35.063 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.unpackHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047096477 > 2017-05-29 08:38:35.065 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.067 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.072 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS > 2017-05-29 08:38:35.073 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.075 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.076 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.077 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.078 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.094 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.104 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.105 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.111 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.112 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.114 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids new recoveryXids org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:899b:592bd946:b, node_name=1, branch_uid=0:ffffac110004:899b:592bd946:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.116 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen put nextScan org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.118 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.118 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.119 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.122 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee > > 2017-05-29 08:38:35.122 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.123 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 171 record > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager::StateManager( 0:0:0:0:0 ) > 2017-05-29 08:38:35.124 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : AbstractRecord::AbstractRecord () - crash recovery constructor > 2017-05-29 08:38:35.126 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Unpacked a 463 record > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : HeuristicList - Unpacked heuristic list size of 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action status of ActionStatus.COMMITTING 6 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored action type Top-level 0 > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 > 2017-05-29 08:38:35.127 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2 recovering 0:ffffac110004:857c:592bddb6:b ActionStatus is ActionStatus.COMMITTED > 2017-05-29 08:38:35.127 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::phase2Commit() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.130 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >) > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 3e8225ee >, record id=0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->FIRST_PASS > 2017-05-29 08:38:35.131 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - first pass > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : InputObjectState::InputObjectState() > 2017-05-29 08:38:35.131 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState() > 2017-05-29 08:38:35.141 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : connect > 2017-05-29 08:38:35.146 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.147 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 16777216 > 2017-05-29 08:38:35.149 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Found 2 xids in doubt > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-119-1018943-39700001149, 0000000000-1-1-84170400-119-1018943-39700001600000000 > > 2017-05-29 08:38:35.150 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Recovered: < 131077, 29, 36, 0000000000-1-1-84170400-1231248943-35-740001149, 0000000000-1-1-84170400-1231248943-35-740001600000000 > > 2017-05-29 08:38:35.151 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids updateIfEquivalentRM1 org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 > 2017-05-29 08:38:35.151 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.151 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.152 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change FIRST_PASS->IDLE > 2017-05-29 08:38:35.154 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:c, subordinatenodename=null, eis_name=0 > > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:d > 2017-05-29 08:38:35.155 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:d) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.156 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit (XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >) > 2017-05-29 08:38:35.157 TRACE 1 --- [riodic Recovery] com.arjuna.ats.jta : XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ee9973f >, record id=0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.165 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016036: commit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac110004:857c:592bddb6:b, node_name=1, branch_uid=0:ffffac110004:857c:592bddb6:10, subordinatenodename=null, eis_name=0 > (org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596) failed with exception $- > java.lang.IllegalStateException: Connection has not been opened > at org.springframework.util.Assert.state(Assert.java:70) ~[spring-core-4.3.9.BUILD-SNAPSHOT.jar!/:4.3.9.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.getDelegate(DataSourceXAResourceRecoveryHelper.java:188) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.commit(DataSourceXAResourceRecoveryHelper.java:159) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:473) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2892) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2808) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1873) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) [arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction.doCommit for 0:ffffac110004:857c:592bddb6:b received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2017-05-29 08:38:35.165 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecordList::insert(RecordList: 0:ffffac110004:857c:592bddb6:d) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffac110004:857c:592bddb6:11 > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::doCommit() result for action-id (0:ffffac110004:857c:592bddb6:b) on record id: (0:ffffac110004:857c:592bddb6:11) is (TwoPhaseOutcome.FINISH_ERROR) node id: (1) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::updateState() for action-id 0:ffffac110004:857c:592bddb6:b > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : OutputObjectState::OutputObjectState(0:ffffac110004:857c:592bddb6:b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2017-05-29 08:38:35.168 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state () > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : StateManager.packHeader for object-id 0:ffffac110004:857c:592bddb6:b birth-date 1496047115170 > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.170 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : BasicAction::save_state - next record to pack is a 171 record /StateManager/AbstractRecord/XAResourceRecord should save it? = true > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a 171 record > 2017-05-29 08:38:35.171 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing a NONE_RECORD > 2017-05-29 08:38:35.172 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Packing action status of ActionStatus.COMMITTED > 2017-05-29 08:38:35.193 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoverAtomicAction.replayPhase2( 0:ffffac110004:857c:592bddb6:b ) finished > 2017-05-29 08:38:35.194 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.195 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change IDLE->SECOND_PASS > 2017-05-29 08:38:35.196 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule - second pass > 2017-05-29 08:38:35.197 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.transactionInitiatedRecovery completed > 2017-05-29 08:38:35.198 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : xarecovery second pass of org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 > 2017-05-29 08:38:35.199 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids _whenFirstSeen toRecover no org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115114 === 1496047115199 > 2017-05-29 08:38:35.200 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Have 0 Xids to recover on this pass. > 2017-05-29 08:38:35.200 WARN 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : recover 8388608 > 2017-05-29 08:38:35.201 INFO 1 --- [riodic Recovery] b.j.n.DataSourceXAResourceRecoveryHelper : disconnect > 2017-05-29 08:38:35.203 WARN 1 --- [riodic Recovery] com.arjuna.ats.jta : ARJUNA016009: Caught: > java.lang.NullPointerException: null > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.disconnect(DataSourceXAResourceRecoveryHelper.java:131) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper.recover(DataSourceXAResourceRecoveryHelper.java:123) ~[spring-boot-1.5.4.BUILD-SNAPSHOT.jar!/:1.5.4.BUILD-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:481) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:232) ~[jta-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) ~[arjuna-5.6.0.Final-SNAPSHOT.jar!/:5.6.0.Final-SNAPSHOT] > 2017-05-29 08:38:35.203 TRACE 1 --- [riodic Recovery] com.arjuna.ats.arjuna : RecoveryXids isStale Check org.springframework.boot.jta.narayana.DataSourceXAResourceRecoveryHelper at 756c6596 1496047115150 1496047115203 false > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.jta : Local XARecoveryModule.resourceInitiatedRecovery completed > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : XARecoveryModule state change SECOND_PASS->IDLE > 2017-05-29 08:38:35.203 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : Moving to the next recovery module > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread Status <== INACTIVE > 2017-05-29 08:38:35.204 DEBUG 1 --- [riodic Recovery] com.arjuna.ats.arjuna : PeriodicRecovery: background thread backing off > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:13:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2908. ------------------------------- > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.6.2.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:13:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2907. ------------------------------- > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2909) Use interposed sync for Transactional Driver close connection call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2909. ------------------------------- Resolution: Done > Use interposed sync for Transactional Driver close connection call > ------------------------------------------------------------------ > > Key: JBTM-2909 > URL: https://issues.jboss.org/browse/JBTM-2909 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > HHH registers as an interposed sync so we need to so we can close after it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:35:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2909) Use interposed sync for Transactional Driver close connection call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2909: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Use interposed sync for Transactional Driver close connection call > ------------------------------------------------------------------ > > Key: JBTM-2909 > URL: https://issues.jboss.org/browse/JBTM-2909 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > HHH registers as an interposed sync so we need to so we can close after it. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2910: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2910) Don't allow transactional driver recovery handler to close underlying JDBC connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2910. ------------------------------- Resolution: Done > Don't allow transactional driver recovery handler to close underlying JDBC connection > ------------------------------------------------------------------------------------- > > Key: JBTM-2910 > URL: https://issues.jboss.org/browse/JBTM-2910 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > As the reference to the JDBC2RecoveryConnection is not retained, it is eligible for garbage collection. It's finalizer calls the connection close and can prevent recovery from completing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2911: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Allow BasicXARecovery to be rescanned by periodic recovery > ---------------------------------------------------------- > > Key: JBTM-2911 > URL: https://issues.jboss.org/browse/JBTM-2911 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Fix For: 5.6.2.Final > > > Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2911) Allow BasicXARecovery to be rescanned by periodic recovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2911. ------------------------------- Resolution: Done > Allow BasicXARecovery to be rescanned by periodic recovery > ---------------------------------------------------------- > > Key: JBTM-2911 > URL: https://issues.jboss.org/browse/JBTM-2911 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Fix For: 5.6.2.Final > > > Currently BasicXARecovery will only return it's configured XAResources for the first periodic recovery scan. It would be useful to allow it to return the same set in subsequent executions of periodic recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2905: --------------------------------- > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.6.2.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2905: -------------------------------- Issue Type: Enhancement (was: Bug) > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.6.2.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jun 21 11:40:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Jun 2017 11:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2905) JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2905. ------------------------------- Resolution: Done > JCAServerTransactionHeaderReader is placed under tests package which makes troubles for tooling > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2905 > URL: https://issues.jboss.org/browse/JBTM-2905 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.6.2.Final > > > The class {{JCAServerTransactionHeaderReader}} is placed under package {{com.hp.mwtests.ts.jta.jts.tools.}} which means is not available during runtime of tooling. As the header reader is used by {{com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser}} it brings situations where the record can't be loaded by tooling. The browser seems to be used by Expiry Scanner and that suffers by that fact. > The WFLY start sequence contains info of not possible to load the reader when the object store contains some unfinished jca subordinate transaction. > {code} > INFO? [com.arjuna.ats.arjuna] (MSC service thread 1-4) ARJUNA012389: OSB: Error constructing record header reader: com.hp.mwtests.ts.jta.jts.tools.JCAServerTransactionHeaderReader from [Module "org.jboss.jts" from local module loader @6b419da (finder: local module finder @3b2da18f (roots: /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules,/home/ochaloup/jboss/jboss-eap-7.1.0.DR19/modules/system/layers/base,/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/modules))] > {code} > The point is to move the jca reader under jts tooling package to be compiled and distributed in the {{jts}} jar. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 22 05:25:00 2017 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Jun 2017 05:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2870) Provide way of getting suppressed exceptions out of SubordinateTransaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425184#comment-13425184 ] RH Bugzilla Integration commented on JBTM-2870: ----------------------------------------------- Petr Penicka changed the Status of [bug 1435549|https://bugzilla.redhat.com/show_bug.cgi?id=1435549] from VERIFIED to CLOSED > Provide way of getting suppressed exceptions out of SubordinateTransaction > -------------------------------------------------------------------------- > > Key: JBTM-2870 > URL: https://issues.jboss.org/browse/JBTM-2870 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Affects Versions: 4.17.38, 5.5.5.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 4.17.40, 5.2.23.Final, 5.5.7.Final, 5.6.0.Final > > > We need to provide way how to pass suppressed exceptions of of the `SubordinateTransaction` to the caller. > This request came from customer case and https://bugzilla.redhat.com/show_bug.cgi?id=1435549 as we need to provide exceptions thrown from transaction resource. > The interface is used for controlling propagated transaction from one server to another in EAP/WFLY. > Callers are is ejb3 subsystem in EAP 6.4/7.0 and WFTC in EAP 7.1. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jun 22 11:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 22 Jun 2017 11:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425557#comment-13425557 ] Tom Jenkinson commented on JBTM-2850: ------------------------------------- JTA spec issue is here: https://github.com/javaee/jta-spec/issues/3 > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.5.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:12 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1789) Simplify deploy plugin configuration and don't deploy uber (shaded) jars In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1789: ----------------------------------- Assignee: (was: Tom Jenkinson) > Simplify deploy plugin configuration and don't deploy uber (shaded) jars > ------------------------------------------------------------------------ > > Key: JBTM-1789 > URL: https://issues.jboss.org/browse/JBTM-1789 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Paul Gier > Fix For: 6.later > > > There is currently configuration of the maven deploy plugin in several modules to either deploy or not deploy artifacts and poms to the Maven repo. The configuration could be simplified using properties, and the uber jars (generated by the shade plugin) should not be deployed to the Maven repository. > Here is the current deployment status and proposed for the modules. > ||Module Name||Current Deployment||Proposed|| > | Narayana: all | deployed | deployed | > | Narayana: common | deployed | deployed | > | Narayana: Arjunacore | deployed | deployed | > | Narayana: ArjunaCore arjuna | deployed | deployed | > | Narayana: ArjunaCore txoj | deployed | deployed | > | Narayana: ArjunaCore arjunacore | deployed | {color:red} skipped {color} | > | Narayana: ArjunaJTA | deployed | deployed | > | Narayana: ArjunaJTA jta | deployed | deployed | > | Narayana: ArjunaJTA cdi | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTA jdbc | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTA narayana-jta | deployed | {color:red} skipped {color} | > | Narayana: XTS | deployed | deployed | > | Narayana: XTS byteman_support | deployed | deployed | > | Narayana: XTS WSAS | skipped | skipped | > | Narayana: XTS WSAS xts-test-servlet | skipped | skipped | > | Narayana: XTS WS-C | skipped | skipped | > | Narayana: XTS WSCF | skipped | skipped | > | Narayana: XTS WS-T | skipped | skipped | > | Narayana: XTS WSTX | skipped | skipped | > | Narayana: XTS recovery | skipped | skipped | > | Narayana: XTS bridge | skipped | skipped | > | Narayana: XTS sar | skipped | skipped | > | Narayana: XTS jbossxts | deployed | deployed | > | Narayana: XTS localjunit | skipped | skipped | > | Narayana: XTS localjunit unit | skipped | skipped | > | Narayana: XTS WSTX11-interop | skipped | skipped | > | Narayana: XTS WSTFSC07-interop | skipped | skipped | > | Narayana: XTS localjunit xtstest | skipped | skipped | > | Narayana: XTS localjunit crash-recovery-tests | skipped | skipped | > | Narayana: ArjunaJTS | deployed | deployed | > | Narayana: ArjunaJTS idl | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS idl jacorb | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS orbportability | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS jts | skipped | {color:red} deployed {color} | > | Narayana: ArjunaJTS jtax | skipped | {color:red} deployed {color} | > | Narayana: ArjuntaJTS narayana-jts-jacorb | deployed | {color:red} skipped {color} | > | Narayana: ArjunaJTS integration | deployed | deployed | > | Narayana: rest-tx | deployed | deployed | > | Narayana: rest-tx util | deployed | deployed | > | Narayana: rest-tx tx (RESTful API for Atomic Transactions) | deployed | deployed | > | Narayana: rest-tx webservice | skipped | skipped | > | Narayana: rest-tx integration | deployed | deployed | > | Narayana: txbridge | deployed | deployed | > | Narayana: fileio | deployed | deployed | > | Narayana: STM | skipped | skipped | > | Narayana: txframework | deployed | deployed | > | Narayana: narayana-full | skipped | skipped | > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:12 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2854) XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2854: ----------------------------------- Assignee: (was: Tom Jenkinson) > XATerminatorImple.importTransaction can produce ArrayIndexOutOfBoundsException > ------------------------------------------------------------------------------ > > Key: JBTM-2854 > URL: https://issues.jboss.org/browse/JBTM-2854 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: David Lloyd > > Here is what the stack trace looks like: > {noformat} > Caused by: Remote exception java.lang.ArrayIndexOutOfBoundsException: 32 > at com.arjuna.ats.jta.xa.XATxConverter.getSubordinateNodeName(XATxConverter.java:204) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:115) > at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.TransactionImple.(TransactionImple.java:57) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.addImportedTransaction(TransactionImporterImple.java:281) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importRemoteTransaction(TransactionImporterImple.java:105) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.importTransaction(XATerminatorImple.java:599) > at org.wildfly.transaction.client.provider.jboss.JBossLocalTransactionProvider$XAImporterImpl.findOrImportTransaction(JBossLocalTransactionProvider.java:585) > ... 11 more > {noformat} > It appears that there is no protection against an XID of inadequate length in XATxConverter#setSubordinateNodeName. > At present the protocol is attempting to import an XID which contains only the gtid from the master node (based on what I discussed with [~tomjenkinson] some time ago at a previous meeting). This can be changed if it is wrong, but either way this method should fail with a friendlier exception if the XID is not valid for some reason. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:12 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:12 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2830) Consider possible compensations framework architecture improvements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2830: ----------------------------------- Assignee: (was: Tom Jenkinson) > Consider possible compensations framework architecture improvements > ------------------------------------------------------------------- > > Key: JBTM-2830 > URL: https://issues.jboss.org/browse/JBTM-2830 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > > I've created a document with a list of possible compensations framework improvements. I'm attaching a link to the google doc for you to review and schedule work once appropriate. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:13 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2194) Activity cancelled by coordinator in CloseTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2194: ----------------------------------- Assignee: (was: Tom Jenkinson) > Activity cancelled by coordinator in CloseTest > ---------------------------------------------- > > Key: JBTM-2194 > URL: https://issues.jboss.org/browse/JBTM-2194 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Fix For: 5.later > > > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.ba.CloseTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.866 sec <<< FAILURE! > testClose(com.arjuna.wstx.tests.arq.ba.CloseTest) Time elapsed: 2.375 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) > at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) > at com.arjuna.wstx.tests.arq.ba.CloseTest.testClose(CloseTest.java:64) > {code} > {code} > 18:45:37,613 INFO [org.jboss.as.repository] (management-handler-thread - 8) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/2a/0685005c0b26622b16a38150f088bad88f5ed8/content > 18:45:37,616 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 18:45:37,860 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 18:45:37,927 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0003: Processing weld deployment test.war > 18:45:37,941 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0006: Starting Services for CDI deployment: test.war > 18:45:37,946 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0009: Starting weld service for deployment test.war > 18:45:38,228 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0021: Registered web context: /test > 18:45:38,406 INFO [org.jboss.as.server] (management-handler-thread - 8) WFLYSRV0010: Deployed "test.war" (runtime-name : "test.war") > 18:45:38,418 INFO [stdout] (Thread-0) TransformListener() : handling connection on port 9091 > 18:45:38,492 INFO [stdout] (Thread-0) retransforming org.jboss.jbossts.xts.bytemanSupport.participantCompletion.ParticipantCompletionCoordinatorRules > 18:45:38,492 INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.engines.ParticipantCompletionCoordinatorEngine > 18:45:38,493 INFO [stdout] (Thread-0) retransforming com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:38,495 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : possible trigger for rule create counter in class org.jboss.jbossts.xts.bytemanSupport.participantCompletion.ParticipantCompletionCoordinatorRules > 18:45:38,496 INFO [stdout] (Thread-0) RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into org.jboss.jbossts.xts.bytemanSupport.participantCompletion.ParticipantCompletionCoordinatorRules.setParticipantCount(java.lang.Integer) void for rule create counter > 18:45:38,497 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : inserted trigger for create counter in class org.jboss.jbossts.xts.bytemanSupport.participantCompletion.ParticipantCompletionCoordinatorRules > 18:45:38,514 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : possible trigger for rule complete called in class com.arjuna.wst11.messaging.engines.ParticipantCompletionCoordinatorEngine > 18:45:38,517 INFO [stdout] (Thread-0) RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into com.arjuna.wst11.messaging.engines.ParticipantCompletionCoordinatorEngine.completed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType,org.jboss.ws.api.addressing.MAP,com.arjuna.webservices11.wsarj.ArjunaContext) void for rule complete called > 18:45:38,536 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : inserted trigger for complete called in class com.arjuna.wst11.messaging.engines.ParticipantCompletionCoordinatorEngine > 18:45:38,552 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : possible trigger for rule cancel called in class com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:38,554 INFO [stdout] (Thread-0) RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl.cancelOperation(com.arjuna.schemas.ws._2005._10.wsarjtx.NotificationType) void for rule cancel called > 18:45:38,556 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : inserted trigger for cancel called in class com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:38,558 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : possible trigger for rule close called in class com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:38,559 INFO [stdout] (Thread-0) RuleTriggerMethodAdapter.injectTriggerPoint : inserting trigger into com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl.closeOperation(com.arjuna.schemas.ws._2005._10.wsarjtx.NotificationType) void for rule close called > 18:45:38,560 INFO [stdout] (Thread-0) org.jboss.byteman.agent.Transformer : inserted trigger for close called in class com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:39,123 INFO [stdout] (default task-16) Rule.execute called for create counter_3 > 18:45:39,124 INFO [stdout] (default task-16) HelperManager.install for helper class org.jboss.byteman.rule.helper.Helper > 18:45:39,124 INFO [stdout] (default task-16) calling activated() for helper class org.jboss.byteman.rule.helper.Helper > 18:45:39,124 INFO [stdout] (default task-16) Default helper activated > 18:45:39,124 INFO [stdout] (default task-16) calling installed(create counter) for helper classorg.jboss.byteman.rule.helper.Helper > 18:45:39,125 INFO [stdout] (default task-16) Installed rule using default helper : create counter > 18:45:39,135 INFO [stdout] (default task-16) create counter execute > 18:45:39,135 INFO [stdout] (default task-16) rule.debug{create counter} : participant_completion.counter.create: 1 > 18:45:39,158 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/wscoor-activation-binding.wsdl > 18:45:39,205 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/wscoor-activation-binding.wsdl > 18:45:39,282 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}RegistrationService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/wscoor-registration-binding.wsdl > 18:45:40,131 WARN [com.arjuna.wst] (default task-16) ARJUNA043225: Could not save recovery state for non-serializable WS-BA participant 1235 > 18:45:40,188 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 18:45:41,372 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (Timer-1) Creating Service {http://docs.oasis-open.org/ws-tx/wsba/2006/06}BusinessAgreementWithParticipantCompletionCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wsba/_2006/_06/wsdl/wsba-participant-completion-coordinator-binding.wsdl > 18:45:42,052 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}RegistrationService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/org/oasis_open/docs/ws_tx/wscoor/_2006/_06/wsdl/wscoor-registration-binding.wsdl > 18:45:42,090 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (default task-16) Creating Service {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationCoordinatorService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/com/arjuna/schemas/ws/_2005/_10/wsarjtx/wsdl/wsarjtx-termination-coordinator-binding.wsdl > 18:45:42,409 INFO [stdout] (default-workqueue-2) Rule.execute called for close called_6 > 18:45:42,410 INFO [stdout] (default-workqueue-2) HelperManager.install for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,411 INFO [stdout] (default-workqueue-2) calling installed(close called) for helper classorg.jboss.byteman.rule.helper.Helper > 18:45:42,411 INFO [stdout] (default-workqueue-2) Installed rule using default helper : close called > 18:45:42,411 INFO [stdout] (default-workqueue-2) close called execute > 18:45:42,412 INFO [stdout] (default-workqueue-2) rule.debug{close called} : participant_completion.close.waiting > 18:45:42,412 INFO [stdout] (TaskWorker-2) Rule.execute called for complete called_4 > 18:45:42,413 INFO [stdout] (TaskWorker-2) HelperManager.install for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,413 INFO [stdout] (TaskWorker-2) calling installed(complete called) for helper classorg.jboss.byteman.rule.helper.Helper > 18:45:42,413 INFO [stdout] (TaskWorker-2) Installed rule using default helper : complete called > 18:45:42,413 INFO [stdout] (TaskWorker-2) complete called execute > 18:45:42,414 INFO [stdout] (TaskWorker-2) rule.debug{complete called} : participant_completion.counter.decrement > 18:45:42,414 INFO [stdout] (TaskWorker-2) rule.debug{complete called} : participant_completion.called.waking > 18:45:42,414 INFO [stdout] (default-workqueue-2) rule.debug{close called} : participant_completion.close.woken > 18:45:42,415 INFO [stdout] (TaskWorker-2) rule.debug{complete called} : participant_completion.called.donewake > 18:45:42,415 WARN [com.arjuna.mw.wstx] (TaskWorker-2) ARJUNA045062: Coordinator cancelled the activity > 18:45:42,428 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (TaskWorker-2) Creating Service {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationParticipantService from WSDL: jar:file:/home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/org/jboss/xts/main/jbossxts-5.0.3.Final-SNAPSHOT.jar!/com/arjuna/schemas/ws/_2005/_10/wsarjtx/wsdl/wsarjtx-termination-participant-binding.wsdl > 18:45:42,439 INFO [stdout] (TaskWorker-1) Rule.execute called for complete called_4 > 18:45:42,441 INFO [stdout] (TaskWorker-1) complete called execute > 18:45:42,496 INFO [stdout] (Thread-0) TransformListener() : handling connection on port 9091 > 18:45:42,598 INFO [stdout] (Thread-0) retransforming org.jboss.jbossts.xts.bytemanSupport.participantCompletion.ParticipantCompletionCoordinatorRules > 18:45:42,599 INFO [stdout] (Thread-0) retransforming com.arjuna.wst11.messaging.engines.ParticipantCompletionCoordinatorEngine > 18:45:42,599 INFO [stdout] (Thread-0) retransforming com.arjuna.webservices11.wsarjtx.sei.TerminationCoordinatorPortTypeImpl > 18:45:42,815 INFO [stdout] (Thread-0) HelperManager.uninstall for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,816 INFO [stdout] (Thread-0) calling uninstalled(create counter) for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,816 INFO [stdout] (Thread-0) Uninstalled rule using default helper : create counter > 18:45:42,817 INFO [stdout] (Thread-0) HelperManager.uninstall for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,817 INFO [stdout] (Thread-0) calling uninstalled(complete called) for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,818 INFO [stdout] (Thread-0) Uninstalled rule using default helper : complete called > 18:45:42,818 INFO [stdout] (Thread-0) HelperManager.uninstall for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,819 INFO [stdout] (Thread-0) calling uninstalled(close called) for helper class org.jboss.byteman.rule.helper.Helper > 18:45:42,819 INFO [stdout] (Thread-0) Uninstalled rule using default helper : close called > 18:45:42,819 INFO [stdout] (Thread-0) calling deactivated() for helper classorg.jboss.byteman.rule.helper.Helper > 18:45:42,820 INFO [stdout] (Thread-0) Default helper deactivated > 18:45:42,830 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0022: Unregistered web context: /test > 18:45:42,845 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0010: Stopping weld service for deployment test.war > 18:45:42,855 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 26ms > 18:45:42,942 INFO [org.jboss.as.repository] (management-handler-thread - 7) WFLYDR0002: Content removed from location /home/hudson/workspace/narayana/PROFILE/XTS/jdk/jdk7.latest/label/linux/jboss-as/build/target/wildfly-9.0.0.Alpha1-SNAPSHOT/standalone/data/content/2a/0685005c0b26622b16a38150f088bad88f5ed8/content > 18:45:42,942 INFO [org.jboss.as.server] (management-handler-thread - 7) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") >  > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:13 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2544) RTS inbound bridge recovery does not work with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2544: ----------------------------------- Assignee: (was: Tom Jenkinson) > RTS inbound bridge recovery does not work with JTS > -------------------------------------------------- > > Key: JBTM-2544 > URL: https://issues.jboss.org/browse/JBTM-2544 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Fix For: 5.later > > > If JTS is enabled, crash scenario when system fails just before the commit does not complete correctly. Instead of being committed, resource is rolled back by XARecoveryModule. > In JTA case, XARecoveryModule does not find any XAResourceRecords and bridge recovery is handled by InboundBridgeRecoveryModule. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:13 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2339) MongoDB extension for Compensations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2339: ----------------------------------- Assignee: (was: Tom Jenkinson) > MongoDB extension for Compensations > ----------------------------------- > > Key: JBTM-2339 > URL: https://issues.jboss.org/browse/JBTM-2339 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Gytis Trikleris > Fix For: 5.later > > > Investigate the feasibility of MongoDB compensations patent implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:13 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:13 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2678: ----------------------------------- Assignee: (was: Tom Jenkinson) > @TxLogged annotation does not work > ---------------------------------- > > Key: JBTM-2678 > URL: https://issues.jboss.org/browse/JBTM-2678 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > > @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2493) REST-AT integration API silently ignores non persistable participants In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2493: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > REST-AT integration API silently ignores non persistable participants > --------------------------------------------------------------------- > > Key: JBTM-2493 > URL: https://issues.jboss.org/browse/JBTM-2493 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The RESTAT integration API Participant interface is serialized during commit processing (in the method org.jboss.narayana.rest.integration.RecoveryManager#persistParticipantInformation) but the interface does not document this responsibility. The javadoc should say something like: > {code} > * Participant implementations must be implement either {@link java.io.Serializable} or {@link PersistableParticipant} > } > Secondly, during commit processing RecoveryManager#persistParticipantInformation needs to throw an exception if the participant cannot be written to the object store. At the moment it just writes a TRACE message. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2483) Investigate ways to test Docker quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2483: ----------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > Investigate ways to test Docker quickstarts > ------------------------------------------- > > Key: JBTM-2483 > URL: https://issues.jboss.org/browse/JBTM-2483 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.later > > > Currently there is only one quickstart for docker (https://github.com/jbosstm/quickstart/tree/master/jts-docker), but its tests are disabled by default. However, it would be good to run them in our CI. > We'll have the same problem in the future with Kubernetes quickstarts. > Maybe Arquillian Cube is something what could help? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2652) Include STM javadocs on narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2652: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Include STM javadocs on narayana.io > ----------------------------------- > > Key: JBTM-2652 > URL: https://issues.jboss.org/browse/JBTM-2652 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation, STM > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2764) Simple Narayana and Tomcat quickstart to demonstrate new module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2764. ------------------------------- Resolution: Done https://github.com/jbosstm/quickstart/tree/master/transactionaldriver-and-tomcat https://github.com/jbosstm/quickstart/tree/master/transactionaldriver-jpa-and-tomcat > Simple Narayana and Tomcat quickstart to demonstrate new module > --------------------------------------------------------------- > > Key: JBTM-2764 > URL: https://issues.jboss.org/browse/JBTM-2764 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > > We should provide one or more examples of Narayana Tomcat module. E.g. one simple example, one more complex example with crash scenario, one example with pooling (depending on the outcome of https://issues.jboss.org/browse/JBTM-2766). -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-1856. --------------------------------- Fix Version/s: (was: 5.later) Resolution: Done https://github.com/jbosstm/quickstart/tree/master/transactionaldriver-and-tomcat https://github.com/jbosstm/quickstart/tree/master/transactionaldriver-jpa-and-tomcat > Provide a transactional driver quickstart > ----------------------------------------- > > Key: JBTM-1856 > URL: https://issues.jboss.org/browse/JBTM-1856 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > > Provide a simple example of a standalone application using Narayana with Transactional Driver. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:15 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:15 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1856. ------------------------------- > Provide a transactional driver quickstart > ----------------------------------------- > > Key: JBTM-1856 > URL: https://issues.jboss.org/browse/JBTM-1856 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > > Provide a simple example of a standalone application using Narayana with Transactional Driver. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:16 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2762) Specify the branch to push on for performance CI script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2762. ------------------------------- Fix Version/s: 5.4.0.Final Resolution: Done > Specify the branch to push on for performance CI script > ------------------------------------------------------- > > Key: JBTM-2762 > URL: https://issues.jboss.org/browse/JBTM-2762 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.4.0.Final > > > fatal: You are pushing to remote 'https://jbosstm-bot**************@github.com/jbosstm/artifacts.git', which is not the upstream of > your current branch 'master', without telling me what to push > to update which remote branch. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:16 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:16 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1107: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 5.later > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2794: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2733: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2756) Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2756: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll > --------------------------------------------------------------------------------------- > > Key: JBTM-2756 > URL: https://issues.jboss.org/browse/JBTM-2756 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Static code analysis category: Nondeterministic locking behavior > _CID-17602_: Bad choice of lock object - Nondeterministic locking behavior > in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block > where lock is acquired at `globalTxAssociations` and `txAssociations`. > The problem (one for txAssociations is described as) > lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`. > lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously. > * Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock. > assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times. > Tom's reaction on this > {quote} > I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread(). > {quote} > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2757) ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2757: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2757 > URL: https://issues.jboss.org/browse/JBTM-2757 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > This issue came from Tom's investigation on JBTM-2756 (which came from static code analysis). > This issue points to the fact that for ThreadAssoction#add [1] tx is used as a getKey but then it overwrites the transactions associated with the thread. This seems to be a bug and need more investigation. > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L66? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2831: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:17 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:17 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-741: ---------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.later > > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:18 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:18 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1863) RESTAT Integration API does not allow participants to leave a transaction early In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1863: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > RESTAT Integration API does not allow participants to leave a transaction early > ------------------------------------------------------------------------------- > > Key: JBTM-1863 > URL: https://issues.jboss.org/browse/JBTM-1863 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 6.later > > > The restat integration API class org.jboss. narayana.rest.integration.api.ParticipantsManager interface does not allow participants to leave the transaction early (in the spec a participant can DELETE the participant-recovery URI to notify the coordinator that it is leaving the transaction early). > Question: The reportHeuristic method allows participants to leave the transaction after the termination protocol has started. To keep the interface simple would it be sensible to replace reportHeuristic with something that covered leaving a transaction at any time or would that be confusing normal operations with error conditions? If so then maybe just the converse of enlist? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1468) Support pure-JTA client and server for WS-AT and REST-AT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1468: ----------------------------------- Assignee: (was: Tom Jenkinson) > Support pure-JTA client and server for WS-AT and REST-AT > -------------------------------------------------------- > > Key: JBTM-1468 > URL: https://issues.jboss.org/browse/JBTM-1468 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: REST, XTS > Reporter: Paul Robinson > Priority: Minor > Fix For: 6.later > > Original Estimate: 2 days > Remaining Estimate: 2 days > > This allows the Client and server application to just use the JTA APIs, whilst having the distribution done over WS-AT or REST-AT. > To do this we need to: > # Remove @Transactional annotation. We then need to use some other mechanism to support the (optional) WS-AT participants that want to use annotations. > # Client side JTA->REST-AT bridge. Needs implementing. > # Server side REST-AT->JTA bridge. Needs integrating into code base. > # Update the TXBridge quickstarts to use this and move them out. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1715: ----------------------------------- Assignee: Ondra Chaloupka (was: Tom Jenkinson) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Paul Robinson > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.later > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1719) Improve test coverage for REST-AT multiplexor. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1719: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Improve test coverage for REST-AT multiplexor. > ---------------------------------------------- > > Key: JBTM-1719 > URL: https://issues.jboss.org/browse/JBTM-1719 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Implement more unit and integration tests to cover more aspects of multiplexor functionality (https://github.com/jbosstm/narayana/tree/master/rts/at/integration). Especially recovery. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1680) Allow 2PC participants to enlist in a compensation-based transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-1680: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Allow 2PC participants to enlist in a compensation-based transaction > -------------------------------------------------------------------- > > Key: JBTM-1680 > URL: https://issues.jboss.org/browse/JBTM-1680 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Paul Robinson > Assignee: Michael Musgrove > Priority: Minor > Fix For: 6.later > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In some situations a developer may need to coordinate multiple resources, where some are 2PC and some are not. Here it could be possible to use enlist the 2PC participants in a compensation-based transaction. The xa.prepare happens in the complete phase, the xa.commit during close and xa.rollback during compensate. > This could provide an alternative to LRCO, where the last resource is compensation-based and the other resources remain 2PC. The benefit of this approach is that the failure window associated with LRCO does not exist. The negative of this approach is that the isolation of the compensation-based participant is reduced. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2372) Create integration test for JBTM-2356 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2372: ----------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > Create integration test for JBTM-2356 > ------------------------------------- > > Key: JBTM-2372 > URL: https://issues.jboss.org/browse/JBTM-2372 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.later > > > There was an integration test for it: https://github.com/jbosstm/narayana/commit/5b278de35b9095a27e27514cca4eea51d8e231cf. > However, it was failing on CI intermittently and had to be reverted. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2629. ------------------------------- Resolution: Out of Date This was done as part of the Spring Boot integration > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2627) Document JMS integration functionality In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2627: ----------------------------------- Assignee: (was: Tom Jenkinson) > Document JMS integration functionality > -------------------------------------- > > Key: JBTM-2627 > URL: https://issues.jboss.org/browse/JBTM-2627 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > > New JMS integration feature needs documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:19 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:19 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2806) Javadoc JMS module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2806: ----------------------------------- Assignee: (was: Tom Jenkinson) > Javadoc JMS module > ------------------ > > Key: JBTM-2806 > URL: https://issues.jboss.org/browse/JBTM-2806 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:20 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2598) Merge in BlackTie Javadocs to main Narayana javadocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2598: ----------------------------------- Assignee: Amos Feng (was: Tom Jenkinson) > Merge in BlackTie Javadocs to main Narayana javadocs > ---------------------------------------------------- > > Key: JBTM-2598 > URL: https://issues.jboss.org/browse/JBTM-2598 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 6.later > > > The BlackTie javadocs are still separate http://narayana.io/documentation/index.html - it would be useful to ensure that they are in the same place as the rest of the Narayana javadocs. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:20 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2713) Investigate why a null FileLock is declared but not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2713: -------------------------------- Issue Type: Bug (was: Task) > Investigate why a null FileLock is declared but not used > -------------------------------------------------------- > > Key: JBTM-2713 > URL: https://issues.jboss.org/browse/JBTM-2713 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > > It is not assigned but later on it is checked for null and if not then released: > https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce12e784fb6/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java#L734 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:21 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:21 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2713) Investigate why a null FileLock is declared but not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2713: ----------------------------------- Assignee: (was: Tom Jenkinson) > Investigate why a null FileLock is declared but not used > -------------------------------------------------------- > > Key: JBTM-2713 > URL: https://issues.jboss.org/browse/JBTM-2713 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Priority: Minor > > It is not assigned but later on it is checked for null and if not then released: > https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce12e784fb6/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java#L734 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:21 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:21 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2180) Determine whether or not we should use a specific collections framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2180: ----------------------------------- Assignee: (was: Tom Jenkinson) > Determine whether or not we should use a specific collections framework > ----------------------------------------------------------------------- > > Key: JBTM-2180 > URL: https://issues.jboss.org/browse/JBTM-2180 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA, JTS, Performance Testing, REST, Transaction Core > Affects Versions: 5.0.1 > Reporter: Mark Little > Priority: Optional > Fix For: 6.later > > > We use many of the inbuilt collections implementations (such as Hashtable) which are well known to be suboptimal in certain cases. Should we use a separate collections framework, e.g., https://github.com/goldmansachs/gs-collections > There are pros and cons of doing this. But first we need to determine whether it really makes sense from a performance perspective. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:22 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:22 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2681) IllegalStateExceptions should contain the stack trace In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2681. ------------------------------- Resolution: Incomplete Description > IllegalStateExceptions should contain the stack trace > ----------------------------------------------------- > > Key: JBTM-2681 > URL: https://issues.jboss.org/browse/JBTM-2681 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Jesper Pedersen > > F.ex. in a place like > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/objectstore/StoreManager.java#L43 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:24 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:24 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2900) Byteman fails to start on IBM JDK (quickstart) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2900: -------------------------------- Fix Version/s: 5.6.0.Final > Byteman fails to start on IBM JDK (quickstart) > ---------------------------------------------- > > Key: JBTM-2900 > URL: https://issues.jboss.org/browse/JBTM-2900 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.2 > Reporter: Ivan Straka > Assignee: Ivan Straka > Priority: Minor > Fix For: 5.6.0.Final > > > Byteman fails to start on IBM JDK for jta-and-hibernate-standalone quickstart. > output: > {code:java} > Running org.jboss.narayana.quickstart.jta.TestCase > byteman jar is /home/hudson/.m2/repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Setting org.jboss.byteman.allow.config.update=true > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:408) > at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:433) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibraryImpl(Native Method) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibrary(Attachment.java:309) > at com.ibm.tools.attach.javaSE.Attachment.parseLoadAgent(Attachment.java:287) > at com.ibm.tools.attach.javaSE.Attachment.doCommand(Attachment.java:168) > at com.ibm.tools.attach.javaSE.Attachment.run(Attachment.java:128) > Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment > at sun.instrument.InstrumentationImpl.addTransformer(InstrumentationImpl.java:100) > Exception in thread "Attachment 45368" Agent failed to start! > at org.jboss.byteman.agent.Main.premain(Main.java:275) > at org.jboss.byteman.agent.Main.agentmain(Main.java:305) > ... 11 more > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jun 23 12:23:24 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 23 Jun 2017 12:23:24 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2900) Byteman fails to start on IBM JDK (quickstart) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2900. ------------------------------- Resolution: Done > Byteman fails to start on IBM JDK (quickstart) > ---------------------------------------------- > > Key: JBTM-2900 > URL: https://issues.jboss.org/browse/JBTM-2900 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 4.2 > Reporter: Ivan Straka > Assignee: Ivan Straka > Priority: Minor > Fix For: 5.6.0.Final > > > Byteman fails to start on IBM JDK for jta-and-hibernate-standalone quickstart. > output: > {code:java} > Running org.jboss.narayana.quickstart.jta.TestCase > byteman jar is /home/hudson/.m2/repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Setting org.jboss.byteman.allow.config.update=true > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:508) > at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:408) > at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:433) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibraryImpl(Native Method) > at com.ibm.tools.attach.javaSE.Attachment.loadAgentLibrary(Attachment.java:309) > at com.ibm.tools.attach.javaSE.Attachment.parseLoadAgent(Attachment.java:287) > at com.ibm.tools.attach.javaSE.Attachment.doCommand(Attachment.java:168) > at com.ibm.tools.attach.javaSE.Attachment.run(Attachment.java:128) > Caused by: java.lang.UnsupportedOperationException: adding retransformable transformers is not supported in this environment > at sun.instrument.InstrumentationImpl.addTransformer(InstrumentationImpl.java:100) > Exception in thread "Attachment 45368" Agent failed to start! > at org.jboss.byteman.agent.Main.premain(Main.java:275) > at org.jboss.byteman.agent.Main.agentmain(Main.java:305) > ... 11 more > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Jun 25 21:05:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Sun, 25 Jun 2017 21:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2895) Upgrade the spring-boot framework version of the quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed JBTM-2895. --------------------------- Fix Version/s: 5.6.0.Final Resolution: Done > Upgrade the spring-boot framework version of the quickstart > ----------------------------------------------------------- > > Key: JBTM-2895 > URL: https://issues.jboss.org/browse/JBTM-2895 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.6.0.Final > > > The current GA release of spring boot is 1.5.3.RELEASE -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Sun Jun 25 21:08:00 2017 From: issues at jboss.org (Amos Feng (JIRA)) Date: Sun, 25 Jun 2017 21:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2820) Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed JBTM-2820. --------------------------- Fix Version/s: 5.5.0.Final Resolution: Done > Quickstart build karaf failed due to can not find the org.apache.felix:gogo-parent 1.0.1-SNAPSHOT > ------------------------------------------------------------------------------------------------- > > Key: JBTM-2820 > URL: https://issues.jboss.org/browse/JBTM-2820 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.5.0.Final > > > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/26 > {code} > [ERROR] Failed to execute goal on project org.apache.karaf.shell.core: Could not resolve dependencies for project org.apache.karaf.shell:org.apache.karaf.shell.core:bundle:4.1.0-SNAPSHOT: Failed to collect dependencies at org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Failed to read artifact descriptor for org.apache.felix:org.apache.felix.gogo.runtime:jar:1.0.1-SNAPSHOT: Could not find artifact org.apache.felix:gogo-parent:pom:1.0.1-SNAPSHOT in apache-snapshots (http://repository.apache.org/content/groups/snapshots-group) -> [Help 1] > {code} > We have to disable the karaf quickstart until the upstream has fixed this issue or the 4.1.0 release -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 04:20:02 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 04:20:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2882) Automatize XTS ssl quickstart to be tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2882: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Automatize XTS ssl quickstart to be tested in CI > ------------------------------------------------ > > Key: JBTM-2882 > URL: https://issues.jboss.org/browse/JBTM-2882 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The ssl XTS quickstart is not automatize to be run in CI testing. Paul created nice document with steps > https://github.com/jbosstm/quickstart/tree/master/XTS/ssl > but it can't be used in CI. > The goal of this enhancement is automatize steps described in the quickstart (plus adjust quickstart REAME.md if not appropriate) and get the quickstart being run in CI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 04:20:02 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 04:20:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2886) Automatize XTS ssl quickstart to be tested in CI on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2886: ------------------------------------- Assignee: (was: Ondra Chaloupka) > Automatize XTS ssl quickstart to be tested in CI on Windows > ----------------------------------------------------------- > > Key: JBTM-2886 > URL: https://issues.jboss.org/browse/JBTM-2886 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 4.2 > Reporter: Ondra Chaloupka > > There was created a shell script for JBTM-2882 which automatize testing of XTS over SSL. The steps were already written in `README.md` but that was not run automatically on CI. > The linux version with shell script was provided but we need windows version with `.bat`. This is a followup task to provide the bat script for the automatization on Windows. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:00:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:00:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2906) It's not possible to combine start and end flags in call of XATerminator.recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426629#comment-13426629 ] Ondra Chaloupka commented on JBTM-2906: --------------------------------------- I'm setting this as unassigned. I would get back to it possibly but it's not a high priority. Leaving for anybody interested in taking over. > It's not possible to combine start and end flags in call of XATerminator.recover > --------------------------------------------------------------------------------- > > Key: JBTM-2906 > URL: https://issues.jboss.org/browse/JBTM-2906 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > Current implementation of {{XATerminator.recover}} (either for JTA or JTS) does not permit combining flags to use. > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L323 > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L246 > Flags are expected to be combined as their values are designed to use bitwise operators. Especially {{|}} is handy for starting and ending the recover scan in once. > Currently we need to call > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN); > XATerminator.recover(XAResource.TMENDRSCAN); > {code} > Values are > {code} > XAResource.TMSTARTRSCAN : 16777216 : 1000000000000000000000000 > XAResource.TMENDRSCAN : 8388608 : 100000000000000000000000 > {code} > The way would be ability to call the {{recover}} like this > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:00:14 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:00:14 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2906) It's not possible to combine start and end flags in call of XATerminator.recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2906: ------------------------------------- Assignee: (was: Ondra Chaloupka) > It's not possible to combine start and end flags in call of XATerminator.recover > --------------------------------------------------------------------------------- > > Key: JBTM-2906 > URL: https://issues.jboss.org/browse/JBTM-2906 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.6.1.Final > Reporter: Ondra Chaloupka > Priority: Minor > > Current implementation of {{XATerminator.recover}} (either for JTA or JTS) does not permit combining flags to use. > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L323 > https://github.com/jbosstm/narayana/blob/5.6.1.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L246 > Flags are expected to be combined as their values are designed to use bitwise operators. Especially {{|}} is handy for starting and ending the recover scan in once. > Currently we need to call > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN); > XATerminator.recover(XAResource.TMENDRSCAN); > {code} > Values are > {code} > XAResource.TMSTARTRSCAN : 16777216 : 1000000000000000000000000 > XAResource.TMENDRSCAN : 8388608 : 100000000000000000000000 > {code} > The way would be ability to call the {{recover}} like this > {code} > XATerminator.recover(XAResource.TMSTARTRSCAN | XAResource.TMENDRSCAN); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:03:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2857) Investigate XTS outbound bridge potential nullpointer issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2857: ------------------------------------- Assignee: (was: Ondra Chaloupka) > Investigate XTS outbound bridge potential nullpointer issue > ----------------------------------------------------------- > > Key: JBTM-2857 > URL: https://issues.jboss.org/browse/JBTM-2857 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Priority: Minor > > During working on JBTM-2853 it was found `NullPointer` could be potentially thrown from `OutboundBridgeManager` when `getTransaction()` returns `null`. It's at time when thread is not associated with any txn. > Discussion about this at PR: https://github.com/jbosstm/narayana/pull/1133 > ``` > Transaction transaction = (Transaction)TransactionManager.transactionManager().getTransaction(); > ``` > https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/org/jboss/jbossts/txbridge/outbound/OutboundBridgeManager.java#L69 > Goal is to investigate this potential exception being trouble or not and if such thing could happen or not. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:04:02 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2757) ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2757: ------------------------------------- Assignee: (was: Ondra Chaloupka) > ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2757 > URL: https://issues.jboss.org/browse/JBTM-2757 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > > This issue came from Tom's investigation on JBTM-2756 (which came from static code analysis). > This issue points to the fact that for ThreadAssoction#add [1] tx is used as a getKey but then it overwrites the transactions associated with the thread. This seems to be a bug and need more investigation. > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L66? -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:04:02 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2756) Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2756: ------------------------------------- Assignee: (was: Ondra Chaloupka) > Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll > --------------------------------------------------------------------------------------- > > Key: JBTM-2756 > URL: https://issues.jboss.org/browse/JBTM-2756 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > > Static code analysis category: Nondeterministic locking behavior > _CID-17602_: Bad choice of lock object - Nondeterministic locking behavior > in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block > where lock is acquired at `globalTxAssociations` and `txAssociations`. > The problem (one for txAssociations is described as) > lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`. > lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously. > * Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock. > assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times. > Tom's reaction on this > {quote} > I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread(). > {quote} > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L125 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:06:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2794: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reopened JBTM-2794: ----------------------------------- > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:15:02 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:15:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2794) Javadoc compensations framework In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426645#comment-13426645 ] Ondra Chaloupka commented on JBTM-2794: --------------------------------------- Ah, my wrong in closing the issue. I mixed it with the https://github.com/jbosstm/narayana/pull/1165 This issue will be fixed when https://github.com/jbosstm/narayana/pull/1166 will be committed. But there are functional issues with the recovery modules delay stopping of the container. When the functional issue is fixed the PR could be committed with fixes of javadoc too. > Javadoc compensations framework > ------------------------------- > > Key: JBTM-2794 > URL: https://issues.jboss.org/browse/JBTM-2794 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Compensations framework internal classes do not have javadocs. They should be documented to make maintenance easier in the future. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:16:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1715) NPE when using CompensationManager within an in-flowed WS-BA transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-1715: ------------------------------------- Assignee: (was: Ondra Chaloupka) > NPE when using CompensationManager within an in-flowed WS-BA transaction > ------------------------------------------------------------------------ > > Key: JBTM-1715 > URL: https://issues.jboss.org/browse/JBTM-1715 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Paul Robinson > Priority: Minor > Fix For: 5.later > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > The following error occurs if an injected CompensationManager is invoked within the scope of a compensation-based transaction that was in-flowed via a WS-BA transaction. > {quote} > 16:17:09,879 ERROR [org.jboss.as.ejb3.invocation] (default task-18) JBAS014134: EJB Invocation failed on component TestServiceService for method public void org.jboss.narayana.compensations.functiona[617/9100] > ted.TestServiceService.saveDataCancelOnFailure(java.lang.Boolean): javax.ejb.EJBException: java.lang.NullPointerException > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:251) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:316) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:215) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:289) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPS > HOT] > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 08:16:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 26 Jun 2017 08:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-741) Remove redundant XTS classes and code paths identified from coverage data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-741: ------------------------------------ Assignee: (was: Ondra Chaloupka) > Remove redundant XTS classes and code paths identified from coverage data > ------------------------------------------------------------------------- > > Key: JBTM-741 > URL: https://issues.jboss.org/browse/JBTM-741 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Affects Versions: 4.11.0 > Reporter: Andrew Dinn > Priority: Minor > Fix For: 5.later > > > Coverage analysis of the XTS code base has idenitifed a lot of unexercised classes and code paths. These need pruning in order to simplify maintenance and testing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 10:01:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 26 Jun 2017 10:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2912: ----------------------------------- Summary: Upgrade JMS transactional driver to JMS 2.0 Key: JBTM-2912 URL: https://issues.jboss.org/browse/JBTM-2912 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JMS Reporter: Tom Jenkinson Fix For: 5.next The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 10:17:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 26 Jun 2017 10:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1195 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Tom Jenkinson > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jun 26 11:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 26 Jun 2017 11:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of narayana-jta pom.xml In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2913: ----------------------------------- Summary: Make the SPI a true dependency of narayana-jta pom.xml Key: JBTM-2913 URL: https://issues.jboss.org/browse/JBTM-2913 Project: JBoss Transaction Manager Issue Type: Feature Request Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next This means that users can simply import the narayana-jta dependency rather than both it and the SPI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 27 06:43:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Jun 2017 06:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2914) Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2914: ----------------------------------- Summary: Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value Key: JBTM-2914 URL: https://issues.jboss.org/browse/JBTM-2914 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Transaction Core Reporter: Tom Jenkinson Assignee: Amos Feng Fix For: 5.next Issue was discovered during https://issues.jboss.org/browse/JBEAP-11701 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jun 27 06:44:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Jun 2017 06:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2914) Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1197 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2914 > URL: https://issues.jboss.org/browse/JBTM-2914 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > Issue was discovered during https://issues.jboss.org/browse/JBEAP-11701 -- This message was sent by Atlassian JIRA (v7.2.3#72005)