From issues at jboss.org Mon Aug 1 06:35:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 1 Aug 2016 06:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2677) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2677. ------------------------------- Fix Version/s: (was: 5.next) Resolution: Duplicate Issue Duplicate of https://issues.jboss.org/browse/JBTM-2710 > XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2677 > URL: https://issues.jboss.org/browse/JBTM-2677 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.16.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back. > The scenario is following: > There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction. > # RAR is deployed > # RAR opens a java socket where listens for message > # MDB of TestResourceMessageListener is deployed > # test client sends prepare command > # test client sends commit command > # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL > # test client receives error code XAER_RMFAIL > # test client sends recover command > # test client receives number of in-doubt xid - which is one > # test client sends rollback command > # XATerminator calls rollback on the in-doubt xid > # expecting TestXAResource.rollback would be called > After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine). > [1] > {code} > 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 ) > 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 1 07:07:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 1 Aug 2016 07:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2710) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2710: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2710 > URL: https://issues.jboss.org/browse/JBTM-2710 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Fix For: 5.next > > > I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back. > The scenario is following: > There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction. > # RAR is deployed > # RAR opens a java socket where listens for message > # MDB of TestResourceMessageListener is deployed > # test client sends prepare command > # test client sends commit command > # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL > # test client receives error code XAER_RMFAIL > # test client sends recover command > # test client receives number of in-doubt xid - which is one > # test client sends rollback command > # XATerminator calls rollback on the in-doubt xid > # expecting TestXAResource.rollback would be called > After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine). > [1] > {code} > 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 ) > 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 02:01:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 2 Aug 2016 02:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273716#comment-13273716 ] Amos Feng commented on JBTM-2712: --------------------------------- It looks like the upstream issues. > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 02:15:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 2 Aug 2016 02:15:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273725#comment-13273725 ] Amos Feng commented on JBTM-2712: --------------------------------- I kicked a build for narayana-quickstarts to see if it works now > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 04:59:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 04:59:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2714: ------------------------------------- Summary: Remove deprecated Reasteasy API from RTS Key: JBTM-2714 URL: https://issues.jboss.org/browse/JBTM-2714 Project: JBoss Transaction Manager Issue Type: Task Components: REST Reporter: Gytis Trikleris Assignee: Michael Musgrove Priority: Blocker Fix For: 5.next Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 04:59:03 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 04:59:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273787#comment-13273787 ] Gytis Trikleris commented on JBTM-2714: --------------------------------------- See the failure: https://github.com/wildfly/wildfly/pull/9086 > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 05:38:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 05:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2693) jca-and-hibernate quickstart CI failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2693. --------------------------------- Release Notes Text: The error in a log is expected, because one of the test cases simulates adding a duplicate resource to the database. I've updated quickstart's readme to reflect that: https://github.com/jbosstm/quickstart/commit/e558656b2c99fc4daa152d853f6d7d49c0f659a1 Fix Version/s: (was: 5.next) Resolution: Rejected > jca-and-hibernate quickstart CI failure > --------------------------------------- > > Key: JBTM-2693 > URL: https://issues.jboss.org/browse/JBTM-2693 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > > The quickstart fails with a hibernate constraint violation: > CI output: http://172.17.130.4:8083/job/narayana-quickstarts-ipv6/28 > Output: > {quote} > 2016-06-18 07:36:23,944 [main] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Unique index or primary key violation: "UK_6M4FUHXJ4CKIXI1VSB8OSII7R_INDEX_5 ON PUBLIC.CUSTOMER(NAME)"; SQL statement: > insert into Customer (name, id) values (?, ?) [23505-171] > 2016-06-18 07:36:23,947 [main] WARN com.arjuna.ats.arjuna - ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< -180000000000000:22cf30fffe66b53b:d118:5764ebe6:2a, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 1b0a7baf > > javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement > 2016-06-18 07:36:23,944 [main] ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper - Unique index or primary key violation: "UK_6M4FUHXJ4CKIXI1VSB8OSII7R_INDEX_5 ON PUBLIC.CUSTOMER(NAME)"; SQL statement: > insert into Customer (name, id) values (?, ?) [23505-171] > 2016-06-18 07:36:23,947 [main] WARN com.arjuna.ats.arjuna - ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< -180000000000000:22cf30fffe66b53b:d118:5764ebe6:2a, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 1b0a7baf > > javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 05:56:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 05:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273816#comment-13273816 ] Michael Musgrove commented on JBTM-2714: ---------------------------------------- OK I will take a look at that today since I am stalled on the jdk-9 work because of a surefire issue > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:29:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 06:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2715) Note compensations weld dependency in the docs In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2715: ------------------------------------- Summary: Note compensations weld dependency in the docs Key: JBTM-2715 URL: https://issues.jboss.org/browse/JBTM-2715 Project: JBoss Transaction Manager Issue Type: Task Components: Compensations, Documentation Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:31:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 06:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2716: -------------------------------------- Summary: Oracle db is out of space Key: JBTM-2716 URL: https://issues.jboss.org/browse/JBTM-2716 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Affects Versions: 5.3.3.Final Reporter: Michael Musgrove The jdbc tests that use our oracle db on the jenkins CI are failing with: bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM We need to clear up some space -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:31:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 06:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273816#comment-13273816 ] Michael Musgrove edited comment on JBTM-2714 at 8/2/16 6:30 AM: ---------------------------------------------------------------- OK I will take a look at that today since I am stalled on the jdk-9 work because of a surefire issue. An example of the problem is: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ was (Author: mmusgrov): OK I will take a look at that today since I am stalled on the jdk-9 work because of a surefire issue > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:32:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 06:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273816#comment-13273816 ] Michael Musgrove edited comment on JBTM-2714 at 8/2/16 6:31 AM: ---------------------------------------------------------------- OK I will take a look at that today since I am stalled on the jdk-9 work because of a surefire issue. was (Author: mmusgrov): OK I will take a look at that today since I am stalled on the jdk-9 work because of a surefire issue. An example of the problem is: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:32:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 06:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2716: ----------------------------------- Description: The jdbc tests that use our oracle db on the jenkins CI are failing with: bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM We need to clear up some space. An example of the problem is: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ was: The jdbc tests that use our oracle db on the jenkins CI are failing with: bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM We need to clear up some space > Oracle db is out of space > ------------------------- > > Key: JBTM-2716 > URL: https://issues.jboss.org/browse/JBTM-2716 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > > The jdbc tests that use our oracle db on the jenkins CI are failing with: > bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM > We need to clear up some space. An example of the problem is: > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 06:33:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 06:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2715) Note compensations weld dependency in the docs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #38 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Note compensations weld dependency in the docs > ---------------------------------------------- > > Key: JBTM-2715 > URL: https://issues.jboss.org/browse/JBTM-2715 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 07:53:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 2 Aug 2016 07:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2717: ------------------------------------- Summary: XAResourceRecoveryHelper removed in a wrong state Key: JBTM-2717 URL: https://issues.jboss.org/browse/JBTM-2717 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Reporter: Gytis Trikleris Priority: Minor Fix For: 5.next {code} Failed tests: XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 2 16:47:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Aug 2016 16:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2714 started by Michael Musgrove. ---------------------------------------------- > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 02:18:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 3 Aug 2016 02:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2712: ---------------------------- Fix Version/s: 5.next > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 02:20:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 3 Aug 2016 02:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2712. ----------------------------- Resolution: Done The narayana-quickstart build is back to work http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-quickstarts/374/ > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 04:04:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 3 Aug 2016 04:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2718: ------------------------------------- Summary: Make CompensatableActionImpl.WorkInfo class static Key: JBTM-2718 URL: https://issues.jboss.org/browse/JBTM-2718 Project: JBoss Transaction Manager Issue Type: Task Components: Compensations Reporter: Gytis Trikleris Priority: Trivial Fix For: 5.next If inner class does not require access to an enclosing instance there should be preffered to use inner static class. (21902 SIC: Inner class could be made static This class is an inner class, but does not use its embedded reference to the object which created it.) As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 04:04:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 3 Aug 2016 04:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2718: ------------------------------------- Assignee: Gytis Trikleris > Make CompensatableActionImpl.WorkInfo class static > -------------------------------------------------- > > Key: JBTM-2718 > URL: https://issues.jboss.org/browse/JBTM-2718 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Trivial > Fix For: 5.next > > > If inner class does not require access to an enclosing instance there should be preffered to use inner static class. > (21902 SIC: Inner class could be made static > This class is an inner class, but does not use its embedded reference to the object which created it.) > As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 05:51:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 3 Aug 2016 05:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1040 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Make CompensatableActionImpl.WorkInfo class static > -------------------------------------------------- > > Key: JBTM-2718 > URL: https://issues.jboss.org/browse/JBTM-2718 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Trivial > Fix For: 5.next > > > If inner class does not require access to an enclosing instance there should be preffered to use inner static class. > (21902 SIC: Inner class could be made static > This class is an inner class, but does not use its embedded reference to the object which created it.) > As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 12:05:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 3 Aug 2016 12:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2714: ----------------------------------- Priority: Major (was: Blocker) > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 12:07:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 3 Aug 2016 12:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274657#comment-13274657 ] Michael Musgrove commented on JBTM-2714: ---------------------------------------- I have dropped the priority since the [pull request | https://github.com/wildfly/wildfly/pull/9086] that upgraded resteasy has been closed. > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 12:17:00 2016 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 3 Aug 2016 12:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274669#comment-13274669 ] Alessio Soldano commented on JBTM-2714: --------------------------------------- I've actually closed the PR as it won't be merged like this (I understand you need to change your code, release, push the upgrade, etc). The sooner you have cycles for working on this topic, the better :-) > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 12:19:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 3 Aug 2016 12:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274670#comment-13274670 ] Michael Musgrove commented on JBTM-2714: ---------------------------------------- Yes, I have just about finished the fix. I will try and get it merged tomorrow after which we can plan a release and get that into wildfly master. > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 12:20:00 2016 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 3 Aug 2016 12:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274671#comment-13274671 ] Alessio Soldano commented on JBTM-2714: --------------------------------------- Cool, thanks > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 3 17:32:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 3 Aug 2016 17:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1041 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2691) Add jms module to narayana-* uber jars In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2691: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add jms module to narayana-* uber jars > -------------------------------------- > > Key: JBTM-2691 > URL: https://issues.jboss.org/browse/JBTM-2691 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This would match transactional driver (jdbc) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2694) Use InVM connector factory for JMS integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2694: ----------------------------------- Assignee: Tom Jenkinson > Use InVM connector factory for JMS integration tests > ---------------------------------------------------- > > Key: JBTM-2694 > URL: https://issues.jboss.org/browse/JBTM-2694 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Port 61616 doesn't work reliably on Windows boxes: > http://stackoverflow.com/questions/11700233/activemq-cant-run-due-to-address-already-in-use-error > Move tests to using InVM connector -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2694) Use InVM connector factory for JMS integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2694: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use InVM connector factory for JMS integration tests > ---------------------------------------------------- > > Key: JBTM-2694 > URL: https://issues.jboss.org/browse/JBTM-2694 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Port 61616 doesn't work reliably on Windows boxes: > http://stackoverflow.com/questions/11700233/activemq-cant-run-due-to-address-already-in-use-error > Move tests to using InVM connector -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:45:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274989#comment-13274989 ] Tom Jenkinson commented on JBTM-2458: ------------------------------------- What was the resolution? > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2660: --------------------------------- > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2660) multiple jars provide the same package:javax/transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2660. ------------------------------- Fix Version/s: (was: 5.next) Resolution: Duplicate Issue Duplicate of JBTM-2663 > multiple jars provide the same package:javax/transaction > -------------------------------------------------------- > > Key: JBTM-2660 > URL: https://issues.jboss.org/browse/JBTM-2660 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Split package, multiple jars provide the same package:javax/transaction > Use Import/Export Package directive -split-package:=(merge-first|merge-last|error|first) to get rid of this warning > Package found in [Jar:jboss-transaction-api_1.2_spec, Jar:jboss-transaction-api_1.1_spec] > Class path [Jar:., Jar:org.osgi.core, Jar:org.osgi.compendium, Jar:jbosgi-metadata, Jar:jboss-transaction-api_1.2_spec, Jar:jta, Jar:common, Jar:arjuna, Jar:jconsole, Jar:jboss-transaction-spi, Jar:jboss-connector-api_1.5_spec, Jar:jboss-transaction-api_1.1_spec, Jar:narayana-jts-integration, Jar:jboss-logging, Jar:artemis-journal, Jar:artemis-commons, Jar:jboss-logmanager, Jar:netty-all, Jar:commons-beanutils, Jar:commons-collections, Jar:guava, Jar:artemis-native, Jar:spring-tx, Jar:aopalliance, Jar:spring-aop, Jar:spring-asm, Jar:spring-beans, Jar:spring-context, Jar:spring-expression, Jar:spring-core, Jar:commons-logging] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2709: ----------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next, 4.17.35 > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2712: -------------------------------- Fix Version/s: (was: 5.next) > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2712. ------------------------------- > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 06:50:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 4 Aug 2016 06:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2667) JDBC Connection leak with Postgres In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2667: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JDBC Connection leak with Postgres > ---------------------------------- > > Key: JBTM-2667 > URL: https://issues.jboss.org/browse/JBTM-2667 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Assignee: Tom Jenkinson > Fix For: 5.next > > > When using Narayana's JDBC TransactionalDriver with a Postgres XA datasource, the connections are never closed. > The problem can be workarounded by adding a modifier : > {code:java} > ModifierFactory.putModifier ("postgresql native driver", -1, -1, PsqlConnectionModifier.class.getName()); > {code} > With a modifier, the close method is called on the XAConnection object, with no modifier it's called on the Connection object. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 08:48:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 4 Aug 2016 08:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13275089#comment-13275089 ] Gytis Trikleris commented on JBTM-2458: --------------------------------------- It was implemented in the subtask. > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 19:31:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Aug 2016 19:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1853) RESTAT does not expose recovery URIs after a crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1853: ----------------------------------- Priority: Major (was: Minor) > RESTAT does not expose recovery URIs after a crash > -------------------------------------------------- > > Key: JBTM-1853 > URL: https://issues.jboss.org/browse/JBTM-1853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > The RESTAT coordinator creates a participant-recovery URI during participant enlistment. This URI should exist for as long as the participant participates in the transaction including during recovery time. After a coordinator crash GET requests return 404 instead of returning the participant resource URI -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 4 19:32:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Aug 2016 19:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1853) RESTAT does not expose recovery URIs after a crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13275412#comment-13275412 ] Michael Musgrove commented on JBTM-1853: ---------------------------------------- Upgraded to priority Major since the fix for JBTM-2714 relies on this functionality. > RESTAT does not expose recovery URIs after a crash > -------------------------------------------------- > > Key: JBTM-1853 > URL: https://issues.jboss.org/browse/JBTM-1853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.0.0.M3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > The RESTAT coordinator creates a participant-recovery URI during participant enlistment. This URI should exist for as long as the participant participates in the transaction including during recovery time. After a coordinator crash GET requests return 404 instead of returning the participant resource URI -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 5 04:02:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 5 Aug 2016 04:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2715) Note compensations weld dependency in the docs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2715: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Note compensations weld dependency in the docs > ---------------------------------------------- > > Key: JBTM-2715 > URL: https://issues.jboss.org/browse/JBTM-2715 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 5 04:04:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 5 Aug 2016 04:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2718: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Make CompensatableActionImpl.WorkInfo class static > -------------------------------------------------- > > Key: JBTM-2718 > URL: https://issues.jboss.org/browse/JBTM-2718 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Trivial > Fix For: 5.next > > > If inner class does not require access to an enclosing instance there should be preffered to use inner static class. > (21902 SIC: Inner class could be made static > This class is an inner class, but does not use its embedded reference to the object which created it.) > As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 5 04:11:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 5 Aug 2016 04:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13275544#comment-13275544 ] Michael Musgrove commented on JBTM-2714: ---------------------------------------- One of the tests in the PR failed and I believe it is related to JBTM-1852. I tried a fix for it but haven't finished testing it yet. > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 02:36:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 9 Aug 2016 02:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2719) tpcall get three seconds delay in the fooapp quickstart In-Reply-To: References: Message-ID: Amos Feng created JBTM-2719: ------------------------------- Summary: tpcall get three seconds delay in the fooapp quickstart Key: JBTM-2719 URL: https://issues.jboss.org/browse/JBTM-2719 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie, Demonstrator Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The apr_pollset_poll in HybridSocketEndpointQueue.cxx Line 392 is blocking and timing out after 3 second. It is the root cause for the tpcall delaying. So it should try to wake up the polling in non-conversation session while disconnect -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 02:45:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 9 Aug 2016 02:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2719) tpcall get three seconds delay in the fooapp quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1045 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > tpcall get three seconds delay in the fooapp quickstart > ------------------------------------------------------- > > Key: JBTM-2719 > URL: https://issues.jboss.org/browse/JBTM-2719 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The apr_pollset_poll in HybridSocketEndpointQueue.cxx Line 392 is blocking and timing out after 3 second. It is the root cause for the tpcall delaying. > So it should try to wake up the polling in non-conversation session while disconnect -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 06:18:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Aug 2016 06:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved JBEAP-5577 to JBTM-2720: -------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2720 (was: JBEAP-5577) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Recovery (was: Transactions) Affects Version/s: (was: 7.backlog.GA) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 06:45:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Aug 2016 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #39 in GitHub ------------------------------------------------------------------------------------------ Status: Pull Request Sent (was: Open) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 09:20:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Aug 2016 09:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2721) Downgrade the version of WildFly to last released version In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2721: ----------------------------------- Summary: Downgrade the version of WildFly to last released version Key: JBTM-2721 URL: https://issues.jboss.org/browse/JBTM-2721 Project: JBoss Transaction Manager Issue Type: Task Components: BlackTie, Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Minor Fix For: 5.next This would be useful in cases like https://developer.jboss.org/message/961052#961052 where the snapshot is not in nexus. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 09:27:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Aug 2016 09:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2721) Downgrade the version of WildFly to last released version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276731#comment-13276731 ] Tom Jenkinson commented on JBTM-2721: ------------------------------------- Occasionally we do need to use the SNAPSHOT if there is something fundamentally altered in WildFly unfortunately. > Downgrade the version of WildFly to last released version > --------------------------------------------------------- > > Key: JBTM-2721 > URL: https://issues.jboss.org/browse/JBTM-2721 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > This would be useful in cases like https://developer.jboss.org/message/961052#961052 where the snapshot is not in nexus. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 16:22:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 9 Aug 2016 16:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: Tomasz Adamski created JBTM-2722: ------------------------------------ Summary: AtomicTransaction equals method is incorrect Key: JBTM-2722 URL: https://issues.jboss.org/browse/JBTM-2722 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.3.3.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 9 16:23:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 9 Aug 2016 16:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2722: --------------------------------- Description: Method returns false even for equal objects. > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 03:26:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 10 Aug 2016 03:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2723: ------------------------------- Summary: Upgrade the apr to 1.5 Key: JBTM-2723 URL: https://issues.jboss.org/browse/JBTM-2723 Project: JBoss Transaction Manager Issue Type: Task Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 07:55:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Aug 2016 07:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2724: -------------------------------------- Summary: Blacktie should not override maven-assembly-plugin version from parent Key: JBTM-2724 URL: https://issues.jboss.org/browse/JBTM-2724 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Affects Versions: 5.3.3.Final Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) Reporter: Michael Musgrove Assignee: Amos Feng One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: {quote} 2.4 {quote} We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 12:27:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Aug 2016 12:27:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2714: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:01:01 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: Tomasz Adamski created JBTM-2725: ------------------------------------ Summary: Race condition in ControlWrapper Key: JBTM-2725 URL: https://issues.jboss.org/browse/JBTM-2725 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTS Affects Versions: 5.3.3.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:05:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 10 Aug 2016 18:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277581#comment-13277581 ] Tom Jenkinson commented on JBTM-2725: ------------------------------------- Hi [~tomekadamski] - any more details? ;) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:06:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2725: --------------------------------- Description: I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction in the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction in the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:08:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277582#comment-13277582 ] Tomasz Adamski commented on JBTM-2725: -------------------------------------- Hey, I usually edit the description after creating JIRA - it is already here ;) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction in the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:11:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277582#comment-13277582 ] Tomasz Adamski edited comment on JBTM-2725 at 8/10/16 6:10 PM: --------------------------------------------------------------- Hey, I usually edit the description after creating JIRA - it is already here ;) Ehh, those errors are intermittent and I hoped this would be the last fix to stop them but unfortunately got another one even with synchronized block - I'm looking at the issue further :/ was (Author: tomekadamski): Hey, I usually edit the description after creating JIRA - it is already here ;) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction in the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:12:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2725: --------------------------------- Description: I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. (was: I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected.) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:12:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2725: --------------------------------- Description: I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. (was: I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction in the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected.) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper the same time they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 10 18:20:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 10 Aug 2016 18:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2725: --------------------------------- Issue Type: Bug (was: Feature Request) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 04:20:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Aug 2016 04:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2716: -------------------------------------- Assignee: Jonathan Halliday > Oracle db is out of space > ------------------------- > > Key: JBTM-2716 > URL: https://issues.jboss.org/browse/JBTM-2716 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Jonathan Halliday > > The jdbc tests that use our oracle db on the jenkins CI are failing with: > bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM > We need to clear up some space. An example of the problem is: > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 04:23:02 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Aug 2016 04:23:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2716. ------------------------------------ Fix Version/s: 5.next Resolution: Done [quote] A couple of releases back oracle added a feature to automatically calculate statistics for all tables, to aid the query planner in optimizing. These histograms live in the system tablespace. And they continue to exist as long as the table does, even if the table is in the recyclebin. So now the metadata about a table ain't quite so small anymore, and we suddenly have a LOT of tables, on account of how they never go away properly." The command 'purge dba_recyclebin' command is the fix. > Oracle db is out of space > ------------------------- > > Key: JBTM-2716 > URL: https://issues.jboss.org/browse/JBTM-2716 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Jonathan Halliday > Fix For: 5.next > > > The jdbc tests that use our oracle db on the jenkins CI are failing with: > bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM > We need to clear up some space. An example of the problem is: > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 04:58:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Aug 2016 04:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2726: ------------------------------------- Summary: Replace deprecated OutputCapture in Spring Boot quickstart test Key: JBTM-2726 URL: https://issues.jboss.org/browse/JBTM-2726 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 04:59:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Aug 2016 04:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #173 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Replace deprecated OutputCapture in Spring Boot quickstart test > --------------------------------------------------------------- > > Key: JBTM-2726 > URL: https://issues.jboss.org/browse/JBTM-2726 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 05:44:02 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 11 Aug 2016 05:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277743#comment-13277743 ] RH Bugzilla Integration commented on JBTM-2614: ----------------------------------------------- Shaun Appleton changed the Status of [bug 1360648|https://bugzilla.redhat.com/show_bug.cgi?id=1360648] from POST to ON_QA > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.13.Final, 4.17.35 > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 05:50:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Aug 2016 05:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2727) Add debug profile In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2727: ------------------------------------- Summary: Add debug profile Key: JBTM-2727 URL: https://issues.jboss.org/browse/JBTM-2727 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Optional Fix For: 5.next Add debug profile to the main pom.xml to make it easier to debug arquillian tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 05:51:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Aug 2016 05:51:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2727) Add debug profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #1048 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add debug profile > ----------------- > > Key: JBTM-2727 > URL: https://issues.jboss.org/browse/JBTM-2727 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.next > > > Add debug profile to the main pom.xml to make it easier to debug arquillian tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 06:26:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Aug 2016 06:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2728: -------------------------------------- Summary: Add a forget operation to the tooling Key: JBTM-2728 URL: https://issues.jboss.org/browse/JBTM-2728 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Tooling Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The tooling provides two features for dealing with heuristic participants: * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; * a delete operation if the admin thinks it safe to do so; In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 06:32:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 11 Aug 2016 06:32:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2724: -------------------------------- Priority: Blocker (was: Major) > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 17:57:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Thu, 11 Aug 2016 17:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tomasz Adamski created pull request #1049 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 18:00:02 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Thu, 11 Aug 2016 18:00:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277582#comment-13277582 ] Tomasz Adamski edited comment on JBTM-2725 at 8/11/16 5:59 PM: --------------------------------------------------------------- Hey, I usually edit the description after creating JIRA - it is already here ;) Ehh, those errors are intermittent and I hoped this would be the last fix to stop them but unfortunately got another one even with synchronized block - I'm looking at the issue further :/ OK - there is lot of ControlWrappers created so synchronized on it's rollback method was not effective. I have synchronized the code on the ControlImple object which (to my understanding) is shared during the whole transaction. After this change the error does not occur. was (Author: tomekadamski): Hey, I usually edit the description after creating JIRA - it is already here ;) Ehh, those errors are intermittent and I hoped this would be the last fix to stop them but unfortunately got another one even with synchronized block - I'm looking at the issue further :/ > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 21:56:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 21:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278235#comment-13278235 ] Amos Feng commented on JBTM-2724: --------------------------------- I will check it the latest plugin to see if it works on the el5 > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 22:30:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 22:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278242#comment-13278242 ] Amos Feng commented on JBTM-2724: --------------------------------- It looks like we have to upgrade the zip from 2.31 to 3.0 in the el5 server. > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 22:31:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 22:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2729) Upgrade the zip to 3.0 in the CI el5 servers In-Reply-To: References: Message-ID: Amos Feng created JBTM-2729: ------------------------------- Summary: Upgrade the zip to 3.0 in the CI el5 servers Key: JBTM-2729 URL: https://issues.jboss.org/browse/JBTM-2729 Project: JBoss Transaction Manager Issue Type: Task Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 22:52:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 22:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2729) Upgrade the zip to 3.0 in the CI el5 servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2729. ----------------------------- Resolution: Done > Upgrade the zip to 3.0 in the CI el5 servers > -------------------------------------------- > > Key: JBTM-2729 > URL: https://issues.jboss.org/browse/JBTM-2729 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 22:53:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 22:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2724: ---------------------------- Fix Version/s: 5.next > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 11 22:53:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 11 Aug 2016 22:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1051 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 06:52:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 12 Aug 2016 06:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2727) Add debug profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2727: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add debug profile > ----------------- > > Key: JBTM-2727 > URL: https://issues.jboss.org/browse/JBTM-2727 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.next > > > Add debug profile to the main pom.xml to make it easier to debug arquillian tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:00:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2724: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:00:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:00:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2542: -------------------------------- Fix Version/s: 5.later (was: 5.next) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2720: -------------------------------- Fix Version/s: 5.next > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:02:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2720: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:02:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2722: -------------------------------- Fix Version/s: 5.next > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:02:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:02:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2722. --------------------------------- Resolution: Done > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:03:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2721) Downgrade the version of WildFly to last released version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2721. --------------------------------- Resolution: Done > Downgrade the version of WildFly to last released version > --------------------------------------------------------- > > Key: JBTM-2721 > URL: https://issues.jboss.org/browse/JBTM-2721 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > This would be useful in cases like https://developer.jboss.org/message/961052#961052 where the snapshot is not in nexus. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:06:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2716: -------------------------------- Fix Version/s: (was: 5.next) > Oracle db is out of space > ------------------------- > > Key: JBTM-2716 > URL: https://issues.jboss.org/browse/JBTM-2716 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Jonathan Halliday > > The jdbc tests that use our oracle db on the jenkins CI are failing with: > bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM > We need to clear up some space. An example of the problem is: > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:06:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2716) Oracle db is out of space In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2716. ------------------------------- > Oracle db is out of space > ------------------------- > > Key: JBTM-2716 > URL: https://issues.jboss.org/browse/JBTM-2716 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Jonathan Halliday > > The jdbc tests that use our oracle db on the jenkins CI are failing with: > bq. unable to extend table SYS.AUD$ by 8192 in tablespace SYSTEM > We need to clear up some space. An example of the problem is: > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/1125/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:07:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2729) Upgrade the zip to 3.0 in the CI el5 servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2729: -------------------------------- Fix Version/s: (was: 5.next) > Upgrade the zip to 3.0 in the CI el5 servers > -------------------------------------------- > > Key: JBTM-2729 > URL: https://issues.jboss.org/browse/JBTM-2729 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:07:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2729) Upgrade the zip to 3.0 in the CI el5 servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2729. ------------------------------- > Upgrade the zip to 3.0 in the CI el5 servers > -------------------------------------------- > > Key: JBTM-2729 > URL: https://issues.jboss.org/browse/JBTM-2729 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:11:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Aug 2016 07:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278395#comment-13278395 ] Michael Musgrove commented on JBTM-2714: ---------------------------------------- PR https://github.com/jbosstm/narayana/pull/1041 was the one that was merged > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 07:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2692) Narayana OSGi bundle is missing optional packages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2692: -------------------------------- Issue Type: Bug (was: Feature Request) > Narayana OSGi bundle is missing optional packages > ------------------------------------------------- > > Key: JBTM-2692 > URL: https://issues.jboss.org/browse/JBTM-2692 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Guillaume Nodet > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > The problem is that the annotations on @Transactional are lost, which makes this annotation unusable in a CDI environment. > Patch below: > {code} > diff --git a/osgi/jta/pom.xml b/osgi/jta/pom.xml > index 87d32c5..cd68637 100644 > --- a/osgi/jta/pom.xml > +++ b/osgi/jta/pom.xml > @@ -206,6 +206,9 @@ > org.apache.felix.service.command, > org.apache.karaf.shell.api.action, > org.apache.karaf.shell.api.action.lifecycle, > + javax.enterprise.util;resolution:=optional, > + javax.interceptor;resolution:=optional > + javax.enterprise.context;resolution:=optional > > true > > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 07:36:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Fri, 12 Aug 2016 07:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277582#comment-13277582 ] Tomasz Adamski edited comment on JBTM-2725 at 8/12/16 7:35 AM: --------------------------------------------------------------- Hey, I usually edit the description after creating JIRA - it is already here ;) There are lot of ControlWrapper objects created so synchronized on it's rollback method is not effective. I have synchronized the code on the ControlImple object which (to my understanding) is shared during the whole transaction. After this change the error does not occur. was (Author: tomekadamski): Hey, I usually edit the description after creating JIRA - it is already here ;) Ehh, those errors are intermittent and I hoped this would be the last fix to stop them but unfortunately got another one even with synchronized block - I'm looking at the issue further :/ OK - there is lot of ControlWrappers created so synchronized on it's rollback method was not effective. I have synchronized the code on the ControlImple object which (to my understanding) is shared during the whole transaction. After this change the error does not occur. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 08:05:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 12 Aug 2016 08:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2730: ------------------------------------- Assignee: Ondra Chaloupka > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 08:05:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 12 Aug 2016 08:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2730: ------------------------------------- Summary: Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered Key: JBTM-2730 URL: https://issues.jboss.org/browse/JBTM-2730 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. I've currently revealed two cases which could cause a trouble: * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. This issue was found by using static code analysis and reacts to report message {code} 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 08:06:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 12 Aug 2016 08:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2730: ---------------------------------- Affects Version/s: 5.3.3.Final > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 08:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 08:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2632. ------------------------------- Fix Version/s: (was: 5.next) Resolution: Duplicate Issue Duplicate of: https://issues.jboss.org/browse/JBTM-2720 > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:05:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 12 Aug 2016 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2730: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1047 > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2727) Add debug profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2727. ------------------------------- > Add debug profile > ----------------- > > Key: JBTM-2727 > URL: https://issues.jboss.org/browse/JBTM-2727 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.3.4.Final > > > Add debug profile to the main pom.xml to make it easier to debug arquillian tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2724. ------------------------------- > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.3.4.Final > > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} > > 2.4 > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2722. ------------------------------- > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.4.Final > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2721) Downgrade the version of WildFly to last released version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2721. ------------------------------- > Downgrade the version of WildFly to last released version > --------------------------------------------------------- > > Key: JBTM-2721 > URL: https://issues.jboss.org/browse/JBTM-2721 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.4.Final > > > This would be useful in cases like https://developer.jboss.org/message/961052#961052 where the snapshot is not in nexus. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2720. ------------------------------- > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2718) Make CompensatableActionImpl.WorkInfo class static In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2718. ------------------------------- > Make CompensatableActionImpl.WorkInfo class static > -------------------------------------------------- > > Key: JBTM-2718 > URL: https://issues.jboss.org/browse/JBTM-2718 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Trivial > Fix For: 5.3.4.Final > > > If inner class does not require access to an enclosing instance there should be preffered to use inner static class. > (21902 SIC: Inner class could be made static > This class is an inner class, but does not use its embedded reference to the object which created it.) > As reference I would mention Joshua Bloch: Effective Java, item 22. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2715) Note compensations weld dependency in the docs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2715. ------------------------------- > Note compensations weld dependency in the docs > ---------------------------------------------- > > Key: JBTM-2715 > URL: https://issues.jboss.org/browse/JBTM-2715 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2714. ------------------------------- > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2711) Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2711. ------------------------------- > Upgrade BlackTie to reference WildFly 11.0.0.Alpha1-SNAPSHOT > ------------------------------------------------------------ > > Key: JBTM-2711 > URL: https://issues.jboss.org/browse/JBTM-2711 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > > WildFly have gone to 11.0.0.Alpha1-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2710) XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2710. ------------------------------- > XATerminator.rollback does not invoke XAResource.rollback for failed resources when JTS is used > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2710 > URL: https://issues.jboss.org/browse/JBTM-2710 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > I do experience an issue of not rollbacking failed XAResource when XATerminator.rollback is called on jca inflow transaction. This works wrong when JTS is used. For the same testcase when JTA is used all in-doubt XAResources are rolled back. > The scenario is following: > There is a a test RA which drives an inflow transaction to a MDB. MDB then works with two TestXAResources which are enlisted to the supplied transaction. > # RAR is deployed > # RAR opens a java socket where listens for message > # MDB of TestResourceMessageListener is deployed > # test client sends prepare command > # test client sends commit command > # first TestXAResource commits, second TestXAResource throws XAException.XAER_RMFAIL > # test client receives error code XAER_RMFAIL > # test client sends recover command > # test client receives number of in-doubt xid - which is one > # test client sends rollback command > # XATerminator calls rollback on the in-doubt xid > # expecting TestXAResource.rollback would be called > After the XATerminator.rollback is invoked there is no call of rollback for the unfinished XAResource. I can see that abort phase is invoked [1] (see attached jboss eap server.log) but the real invocation of the XAResource.rollback does not happen (for the JTA transaction it runs fine). > [1] > {code} > 2016-05-18 11:20:20,385 TRACE [com.arjuna.ats.jts] (default-threads- 1) ServerTransaction::doPhase2Abort (0:ffff7f000001:-728dfa93:573c33bc:24 ) > 2016-05-18 11:20:55,416 TRACE [com.arjuna.ats.jts] (default-threads- 1) ArjunaTransactionImple::get_status for 0:ffff7f000001:-728dfa93:573c33bc:24 returning CosTransactions::StatusCommitted -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2709. ------------------------------- > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final, 4.17.35 > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2708) Test does not close FileInputStream In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2708. ------------------------------- > Test does not close FileInputStream > ----------------------------------- > > Key: JBTM-2708 > URL: https://issues.jboss.org/browse/JBTM-2708 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final, 4.17.35 > > > {code} > public XARRTestResource(String xarrHelper, File file) throws IOException { > this.xarrHelper = xarrHelper; > this.file = file; > DataInputStream fis = new DataInputStream(new FileInputStream(file)); > final int formatId = fis.readInt(); > final int gtrid_length = fis.readInt(); > final byte[] gtrid = new byte[gtrid_length]; > fis.read(gtrid, 0, gtrid_length); > final int bqual_length = fis.readInt(); > final byte[] bqual = new byte[bqual_length]; > fis.read(bqual, 0, bqual_length); > xids.put(file, new Xid() { > @Override > public byte[] getGlobalTransactionId() { > return gtrid; > } > @Override > public int getFormatId() { > return formatId; > } > @Override > public byte[] getBranchQualifier() { > return bqual; > } > }); > fis.close(); > } > {code} > Spotted while working on JBTM-2614 backport -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2707) Update README to reflect accurately which JDK versions we support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2707. ------------------------------- > Update README to reflect accurately which JDK versions we support > ----------------------------------------------------------------- > > Key: JBTM-2707 > URL: https://issues.jboss.org/browse/JBTM-2707 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > We are using Java 1.8 features and the top level README needs to reflect tha. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2703) When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2703. ------------------------------- > When a transaction is committed at the same instance as a resource adapter/remote EJB calls XAT::recover() then you can get an NPE > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2703 > URL: https://issues.jboss.org/browse/JBTM-2703 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > {code} > INFO [com.arjuna.ats.arjuna] ObjectStore record was deleted during restoration, users should not deleted records manually: /ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA: java.io.FileNotFoundException: /ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA/ (No such file or directory) > ERROR [stderr] java.io.IOException: java.lang.NullPointerException > ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:732) > ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.jca.SubordinateAtomicAction.(SubordinateAtomicAction.java:82) > ERROR [stderr] at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.doRecover(XATerminatorImple.java:393) > ERROR [stderr] at org.jboss.as.ejb3.remote.EJBRemoteTransactionsRepository.getXidsToRecoverForParentNode(EJBRemoteTransactionsRepository.java:178) > ERROR [stderr] at org.jboss.as.ejb3.remote.protocol.versiontwo.TransactionRecoverMessageHandler$TxRecoveryTask.run(TransactionRecoverMessageHandler.java:96) > ERROR [stderr] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > ERROR [stderr] at java.util.concurrent.FutureTask.run(FutureTask.java:262) > ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > ERROR [stderr] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > ERROR [stderr] at java.lang.Thread.run(Thread.java:745) > ERROR [stderr] at org.jboss.threads.JBossThread.run(JBossThread.java:122) > ERROR [stderr] Caused by: java.lang.NullPointerException > ERROR [stderr] at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:697) > ERROR [stderr] ... 10 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2699) Simple RTS quickstart doesn't work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2699. ------------------------------- > Simple RTS quickstart doesn't work > ---------------------------------- > > Key: JBTM-2699 > URL: https://issues.jboss.org/browse/JBTM-2699 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > {code} > [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default-cli) on project simple: An exception occured while executing the Java class. null: InvocationTargetException: org/jboss/resteasy/spi/LinkHeader: org.jboss.resteasy.spi.LinkHeader -> [Help 1] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2696) TestGroup_txcore_recovery failure on DB2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2696. ------------------------------- > TestGroup_txcore_recovery failure on DB2 > ---------------------------------------- > > Key: JBTM-2696 > URL: https://issues.jboss.org/browse/JBTM-2696 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.4.Final > > > {code} > [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_txcore_recovery > [junit] Tests run: 36, Failures: 1, Errors: 0, Time elapsed: 3,224.323 sec > [junit] Test org.jboss.jbossts.qa.junit.testgroup.TestGroup_txcore_recovery FAILED > {code} > Recovery_Crash_LockManager_Test008/server_0_output.txt > {code} > 2016-06-25 03:12:45,296 out: 2016-06-25 03:12:45,290 [Periodic Recovery] WARN com.arjuna.ats.txoj - ARJUNA015011: RecoveredTransactionalObject::findHoldingTransaction - exception > 2016-06-25 03:12:45,296 out: java.io.IOException: java.lang.NullPointerException > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:741) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.txoj.recovery.RecoveredTransactionalObject.findHoldingTransaction(RecoveredTransactionalObject.java:175) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.txoj.recovery.RecoveredTransactionalObject.replayPhase2(RecoveredTransactionalObject.java:88) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.txoj.recovery.TORecoveryModule.recoverObject(TORecoveryModule.java:232) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.txoj.recovery.TORecoveryModule.periodicWorkSecondPass(TORecoveryModule.java:183) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:793) > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375) > 2016-06-25 03:12:45,296 out: Caused by: java.lang.NullPointerException > 2016-06-25 03:12:45,296 out: at com.arjuna.ats.arjuna.StateManager.unpackHeader(StateManager.java:706) > 2016-06-25 03:12:45,296 out: ... 6 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2698) GitHub projects don't include the license file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2698. ------------------------------- > GitHub projects don't include the license file > ---------------------------------------------- > > Key: JBTM-2698 > URL: https://issues.jboss.org/browse/JBTM-2698 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: gil cattaneo > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > > hi > Not available LICENSE file in source directory structure > Please. Added license and copyright notice. > the fedora pakaging guideline is very strictly precise about this problem > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Text > Thanks > Regards > p.s. reported also @ https://github.com/jbosstm/jboss-transaction-spi/issues/9 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2694) Use InVM connector factory for JMS integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2694. ------------------------------- > Use InVM connector factory for JMS integration tests > ---------------------------------------------------- > > Key: JBTM-2694 > URL: https://issues.jboss.org/browse/JBTM-2694 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > Port 61616 doesn't work reliably on Windows boxes: > http://stackoverflow.com/questions/11700233/activemq-cant-run-due-to-address-already-in-use-error > Move tests to using InVM connector -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:08:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:08:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2695) Blacktie administration services test deployment fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2695. ------------------------------- > Blacktie administration services test deployment fails > ------------------------------------------------------ > > Key: JBTM-2695 > URL: https://issues.jboss.org/browse/JBTM-2695 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.3.4.Final > > > {code} > T E S T S > ------------------------------------------------------- > Running AdvertiseUnadvertiseTest > 20:38:01,608 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/65/36deb9697994d21be752edb6296e8d3ea4456f/content > 20:38:01,662 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 20:38:02,983 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} > 20:38:02,999 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 12ms > 20:38:03,036 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} > 20:38:03,037 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0186: Services which failed to start: service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.32 sec <<< FAILURE! - in AdvertiseUnadvertiseTest > AdvertiseUnadvertiseTest Time elapsed: 7.319 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > Results : > Tests in error: > AdvertiseUnadvertiseTest.AdvertiseUnadvertiseTest ? Deployment Cannot deploy: ... > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] Blacktie C++ Plugin ................................ SUCCESS [ 16.490 s] > [INFO] BlackTie all files ................................. SUCCESS [ 2.660 s] > [INFO] Blacktie Defaults and Dependencies ................. SUCCESS [ 0.096 s] > [INFO] Blacktie C Defaults and Dependencies ............... SUCCESS [ 7.708 s] > [INFO] Blacktie Java JNI Tests ............................ SUCCESS [ 3.153 s] > [INFO] Blacktie Schemas ................................... SUCCESS [ 2.247 s] > [INFO] BlackTie Messaging (via JMS) ....................... SUCCESS [ 5.733 s] > [INFO] Blacktie Java XATMI Implementation ................. SUCCESS [05:37 min] > [INFO] Blacktie Java NBF Implementation ................... SUCCESS [ 4.431 s] > [INFO] Blacktie Administration Services ................... FAILURE [ 52.390 s] > [INFO] Blacktie Administration Services EAR ............... SKIPPED > [INFO] Blacktie Core C++ Implementation ................... SKIPPED > [INFO] Blacktie Codec C++ Implementation .................. SKIPPED > [INFO] Blacktie C++ REST Transport ........................ SKIPPED > [INFO] Blacktie Utilities ................................. SKIPPED > [INFO] Blacktie C++ TX Client Library ..................... SKIPPED > [INFO] Blacktie C++ Hybrid Transport ...................... SKIPPED > [INFO] Blacktie C++ XATMI Implementation .................. SKIPPED > [INFO] Blacktie C++ Queue Client .......................... SKIPPED > [INFO] Blacktie NBF ....................................... SKIPPED > [INFO] BlackTie Admin CLI Tool ............................ SKIPPED > [INFO] Blacktie Server Code Generation .................... SKIPPED > [INFO] Blacktie Java/C C/Java XATMI Tests ................. SKIPPED > [INFO] Blacktie Distribution .............................. SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 07:36 min > [INFO] Finished at: 2016-06-24T20:38:03+01:00 > [INFO] Final Memory: 60M/144M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project blacktie-admin-services: There are test failures. > [ERROR] > [ERROR] Please refer to /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/blacktie-admin-services/target/surefire-reports for the individual test results. > [ERROR] -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :blacktie-admin-services > UID PID PPID C STIME TTY TIME CMD > hudson 8757 8755 0 Apr12 ? 00:22:38 sshd: hudson at notty > hudson 8835 8757 0 Apr12 ? 00:00:00 bash -c cd "/home/hudson" && java -jar slave.jar > hudson 8852 8835 0 Apr12 ? 01:03:45 java -jar slave.jar > hudson 9476 32418 0 Apr12 ? 00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin > hudson 14629 1 0 Apr08 ? 00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh > hudson 14655 14629 0 Apr08 ? 00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh > hudson 19882 8852 0 20:07 ? 00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh > hudson 19887 19882 0 20:07 ? 00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh > hudson 21590 19887 0 20:30 ? 00:00:00 /bin/sh blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost > hudson 21646 21590 6 20:30 ? 00:00:30 /usr/local/jdk1.8.0_60//bin/java -D[Standalone] -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties -jar /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar -mp /home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT -Djboss.server.base.dir=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone -c standalone-blacktie.xml -Djboss.bind.address=localhost -Djboss.bind.address.unsecure=localhost -Djboss.bind.address.management=localhost > hudson 22528 19887 0 20:38 ? 00:00:00 ps -f > hudson 32418 14655 0 Apr12 ? 00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false > blacktie/wildfly-10.1.0.Final-SNAPSHOT/bin/standalone.sh: line 307: 21646 Killed "/usr/local/jdk1.8.0_60//bin/java" -D"[Standalone]" -server -Xmx256m -XX:MaxPermSize=256m -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -DOrbPortabilityEnvironmentBean.resolveService=NAME_SERVICE "-Dorg.jboss.boot.log.file=/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/log/server.log" "-Dlogging.configuration=file:/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties" -jar "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/jboss-modules.jar" -mp "/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/modules" org.jboss.as.standalone -Djboss.home.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT" -Djboss.server.base.dir="/home/hudson/workspace/narayana/PROFILE/BLACKTIE/jdk/jdk8.latest/label/linux64el5/blacktie/wildfly-10.1.0.Final-SNAPSHOT/standalone" '-c' 'standalone-blacktie.xml' '-Djboss.bind.address=localhost' '-Djboss.bind.address.unsecure=localhost' '-Djboss.bind.address.management=localhost' > pkill: 2508 - Operation not permitted > pkill: 1841 - Operation not permitted > pkill: 3071 - Operation not permitted > pkill: 1413 - Operation not permitted > pkill: 1497 - Operation not permitted > pkill: 1502 - Operation not permitted > pkill: 1503 - Operation not permitted > pkill: 1596 - Operation not permitted > pkill: 2221 - Operation not permitted > UID PID PPID C STIME TTY TIME CMD > hudson 8757 8755 0 Apr12 ? 00:22:38 sshd: hudson at notty > hudson 8835 8757 0 Apr12 ? 00:00:00 bash -c cd "/home/hudson" && java -jar slave.jar > hudson 8852 8835 0 Apr12 ? 01:03:45 java -jar slave.jar > hudson 9476 32418 0 Apr12 ? 00:00:18 /usr/local/jdk1.8.0_60/jre/bin/java -Dnames=.* -Dadditional.elements=-DObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.communicationStore.tablePrefix=Communication -DObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.stateStore.tablePrefix=stateStore -DObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore -DObjectStoreEnvironmentBean.tablePrefix=Action -DObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -DObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DynamicDataSourceJDBCAccess;ClassName=com.ibm.db2.jcc.DB2DataSource;DatabaseName=BTDB1;User=db2;Password=db2;ServerName=tywin.eng.hst.ams2.redhat.com;PortNumber=50001;DriverType=4 -Dtest.timeout= -classpath /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/ext/junit.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/tests/build/jbossts-jts-qa.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/jbossjts.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-commons.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-journal.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/artemis-native.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-beanutils.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-collections.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/commons-logging.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/dom4j.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/guava.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/hamcrest-core.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/ironjacamar-spec-api.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-connector-api_1.5_spec.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-annotations.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-logging-processor.jar:/home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/db2/jdk/jdk8.latest/slave/linux/qa/dist/narayana-full-5.3.3.Final-SNAPSHOT/lib/ext/jboss-loggin > hudson 14629 1 0 Apr08 ? 00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh > hudson 14655 14629 0 Apr08 ? 00:00:00 /bin/bash -xe /tmp/hudson1493082877525066780.sh > hudson 19882 8852 0 20:07 ? 00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh > hudson 19887 19882 0 20:07 ? 00:00:00 /bin/bash -xe /tmp/hudson3887036970646544553.sh > hudson 22539 19887 0 20:38 ? 00:00:00 ps -f > hudson 32418 14655 0 Apr12 ? 00:00:41 /usr/local/jdk1.8.0_60//jre/bin/java -classpath /home/hudson/apache-ant-1.8.2/lib/ant-launcher.jar -Dant.home=/home/hudson/apache-ant-1.8.2 -Dant.library.dir=/home/hudson/apache-ant-1.8.2/lib org.apache.tools.ant.launch.Launcher -cp -f run-tests.xml ci-jts-tests -Dprofile=db2 -Dcode.coverage=false > Some tests failed: http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el5/1101/ > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2692) Narayana OSGi bundle is missing optional packages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2692. ------------------------------- > Narayana OSGi bundle is missing optional packages > ------------------------------------------------- > > Key: JBTM-2692 > URL: https://issues.jboss.org/browse/JBTM-2692 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Guillaume Nodet > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.3.4.Final > > > The problem is that the annotations on @Transactional are lost, which makes this annotation unusable in a CDI environment. > Patch below: > {code} > diff --git a/osgi/jta/pom.xml b/osgi/jta/pom.xml > index 87d32c5..cd68637 100644 > --- a/osgi/jta/pom.xml > +++ b/osgi/jta/pom.xml > @@ -206,6 +206,9 @@ > org.apache.felix.service.command, > org.apache.karaf.shell.api.action, > org.apache.karaf.shell.api.action.lifecycle, > + javax.enterprise.util;resolution:=optional, > + javax.interceptor;resolution:=optional > + javax.enterprise.context;resolution:=optional > > true > > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2689) narayana-osgi-jta integration test does not work with the karaf 4.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2689. ------------------------------- > narayana-osgi-jta integration test does not work with the karaf 4.x > ------------------------------------------------------------------- > > Key: JBTM-2689 > URL: https://issues.jboss.org/browse/JBTM-2689 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.3.4.Final > > > The aquillian-container-karaf-embedded only support the karaf 2.3.3 and we are using the shell command with 4.x > Now we just disable the integration test temperately. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2679) Artifact of narayana-full does not contain bits of jbossxts.jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2679. ------------------------------- > Artifact of narayana-full does not contain bits of jbossxts.jar > --------------------------------------------------------------- > > Key: JBTM-2679 > URL: https://issues.jboss.org/browse/JBTM-2679 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.2.17.Final, 5.3.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.3.4.Final, 5.2.18.Final > > > Zip file {{narayana-full-$VERSION-bin.zip}} under directory {{narayana-full/target}} which is created from the built artifacts does not contains bits of {{jbossxts.jar}}. The artifact for xts with the filename {{jbossxts.jar}} is available but contains the same bits as it's counterpart {{-api}} jar file. > Created assembly plugin jira: https://issues.apache.org/jira/browse/MASSEMBLY-809 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2668) Entity manager does not join transaction properly in JTA and Hibernate quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2668. ------------------------------- > Entity manager does not join transaction properly in JTA and Hibernate quickstart > --------------------------------------------------------------------------------- > > Key: JBTM-2668 > URL: https://issues.jboss.org/browse/JBTM-2668 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.4.Final > > > To reproduce begin transaction at the start of TestCase.testJpa method and roll it back just before assertion. During the abort in BasicAction pending list is empty and no resources are rolled back. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2667) JDBC Connection leak with Postgres In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2667. ------------------------------- > JDBC Connection leak with Postgres > ---------------------------------- > > Key: JBTM-2667 > URL: https://issues.jboss.org/browse/JBTM-2667 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.2.Final > Reporter: Alexis Hassler > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > When using Narayana's JDBC TransactionalDriver with a Postgres XA datasource, the connections are never closed. > The problem can be workarounded by adding a modifier : > {code:java} > ModifierFactory.putModifier ("postgresql native driver", -1, -1, PsqlConnectionModifier.class.getName()); > {code} > With a modifier, the close method is called on the XAConnection object, with no modifier it's called on the Connection object. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2665) Upgrade jboss-transacton-spi dependency to 7.3.2.Final before the next release In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2665. ------------------------------- > Upgrade jboss-transacton-spi dependency to 7.3.2.Final before the next release > ------------------------------------------------------------------------------ > > Key: JBTM-2665 > URL: https://issues.jboss.org/browse/JBTM-2665 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > The OSGI build depends on an upgrade of the jboss-transacton-spi (JBTM-2663) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2624. ------------------------------- > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.4.Final > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2622. ------------------------------- > Implement possible new compensations api > ---------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.4.Final > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2605) Narayana Spring integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2605. ------------------------------- > Narayana Spring integration > --------------------------- > > Key: JBTM-2605 > URL: https://issues.jboss.org/browse/JBTM-2605 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, Documentation, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.4.Final > > > This is a wrapper for all subtasks related with Spring integration. > As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2458. ------------------------------- > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.4.Final > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2728: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2726: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Replace deprecated OutputCapture in Spring Boot quickstart test > --------------------------------------------------------------- > > Key: JBTM-2726 > URL: https://issues.jboss.org/browse/JBTM-2726 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2723: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Upgrade the apr to 1.5 > ---------------------- > > Key: JBTM-2723 > URL: https://issues.jboss.org/browse/JBTM-2723 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2719) tpcall get three seconds delay in the fooapp quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2719: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > tpcall get three seconds delay in the fooapp quickstart > ------------------------------------------------------- > > Key: JBTM-2719 > URL: https://issues.jboss.org/browse/JBTM-2719 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The apr_pollset_poll in HybridSocketEndpointQueue.cxx Line 392 is blocking and timing out after 3 second. It is the root cause for the tpcall delaying. > So it should try to wake up the polling in non-conversation session while disconnect -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2717: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2713) Remove FileLock cruft from LogStore file 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: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Remove FileLock cruft from LogStore file > ---------------------------------------- > > Key: JBTM-2713 > URL: https://issues.jboss.org/browse/JBTM-2713 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > It certainly isn't referenced: > 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 (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2691) Add jms module to narayana-* uber jars In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2691. ------------------------------- > Add jms module to narayana-* uber jars > -------------------------------------- > > Key: JBTM-2691 > URL: https://issues.jboss.org/browse/JBTM-2691 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > This would match transactional driver (jdbc) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2705) Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2705: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs > ------------------------------------------------------------------------------ > > Key: JBTM-2705 > URL: https://issues.jboss.org/browse/JBTM-2705 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > During JTS resource enlistment we create a RecoveryCoordinator IOR and embed recovery information in the ObjectKey part. This is not a portable solution since we need to use ORB vendor specific APIs to modify the ObjectKey. It would be preferable if we could use something that is in the CORBA specs that will work for all ORBs such as Portable Intercpeors (http://www.omg.org/cgi-bin/doc?ptc/2001-03-04). > Note that there is no current solution for IBM orb. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2704: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2701: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > XAR should be scanned more frequently for prepared transactions > --------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2688) Message was not delivered to the queue in Spring Boot QS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2688: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Message was not delivered to the queue in Spring Boot QS > -------------------------------------------------------- > > Key: JBTM-2688 > URL: https://issues.jboss.org/browse/JBTM-2688 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.spring.QuickstartApplicationTests > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.443 sec <<< FAILURE! > testCommit(org.jboss.narayana.quickstart.spring.QuickstartApplicationTests) Time elapsed: 2.43 sec <<< FAILURE! > java.lang.AssertionError: > Expected: a string containing "Message received: Created entry 'Test Value'" > but: was " > . ____ _ __ _ _ > /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ > ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ > \\/ ___)| |_)| | | | | || (_| | ) ) ) ) > ' |____| .__|_| |_|_| |_\__, | / / / / > =========|_|==============|___/=/_/_/_/ > :: Spring Boot :: (v1.4.0.M3) > 2016-06-14 14:34:55.166 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : Starting QuickstartApplication on jaime.eng.hst.ams2.redhat.com with PID 5790 (/home/hudson/workspace/btny-pulls-narayana-quickstart/spring/narayana-spring-boot/target/classes started by hudson in /home/hudson/workspace/btny-pulls-narayana-quickstart/spring/narayana-spring-boot) > 2016-06-14 14:34:55.167 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : No active profile set, falling back to default profiles: default > 2016-06-14 14:34:55.170 INFO 5790 --- [ main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext at 1d0cdb6: startup date [Tue Jun 14 14:34:55 BST 2016]; root of context hierarchy > 2016-06-14 14:34:55.655 INFO 5790 --- [ main] f.a.AutowiredAnnotationBeanPostProcessor : JSR-330 'javax.inject.Inject' annotation found and supported for autowiring > 2016-06-14 14:34:55.787 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032010: JBossTS Recovery Service (tag: unknown) - JBoss Inc. > 2016-06-14 14:34:55.787 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032013: Starting transaction recovery manager > 2016-06-14 14:34:55.870 INFO 5790 --- [ main] o.s.t.jta.JtaTransactionManager : Using JTA UserTransaction: Transaction: unknown > 2016-06-14 14:34:55.870 INFO 5790 --- [ main] o.s.t.jta.JtaTransactionManager : Using JTA TransactionManager: Transaction: unknown > 2016-06-14 14:34:55.980 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Building JPA container EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:55.981 INFO 5790 --- [ main] o.hibernate.jpa.internal.util.LogHelper : HHH000204: Processing PersistenceUnitInfo [ > name: default > ...] > 2016-06-14 14:34:55.995 INFO 5790 --- [ main] org.hibernate.dialect.Dialect : HHH000400: Using dialect: org.hibernate.dialect.H2Dialect > 2016-06-14 14:34:56.040 INFO 5790 --- [ main] o.h.t.schema.internal.SchemaCreatorImpl : HHH000476: Executing import script 'org.hibernate.tool.schema.internal.exec.ScriptSourceInputNonExistentImpl at 637cff' > 2016-06-14 14:34:56.045 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:56.191 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=false,journalDirectory=/tmp/artemis-data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/largemessages,pagingDirectory=data/paging) > 2016-06-14 14:34:56.192 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221045: libaio is not available, switching the configuration into NIO > 2016-06-14 14:34:56.193 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE > 2016-06-14 14:34:56.220 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221003: Trying to deploy queue jms.queue.quickstart-messages > 2016-06-14 14:34:56.231 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221007: Server is now live > 2016-06-14 14:34:56.231 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.2.0 [localhost, nodeID=c852656c-3234-11e6-94cb-52540027ba72] > 2016-06-14 14:34:56.496 INFO 5790 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup > 2016-06-14 14:34:56.503 INFO 5790 --- [ main] o.s.c.support.DefaultLifecycleProcessor : Starting beans in phase 2147483647 > 2016-06-14 14:34:56.509 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : Started QuickstartApplication in 1.418 seconds (JVM running for 10.75) > 2016-06-14 14:34:56.520 INFO 5790 --- [ main] o.h.h.i.QueryTranslatorFactoryInitiator : HHH000397: Using ASTQueryTranslatorFactory > Entries at the start: [] > Creating entry 'Test Value' > Entries at the end: [Entry{id=1, value='Test Value'}] > 2016-06-14 14:34:57.444 INFO 5790 --- [ main] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext at 1d0cdb6: startup date [Tue Jun 14 14:34:55 BST 2016]; root of context hierarchy > 2016-06-14 14:34:57.446 INFO 5790 --- [ main] o.s.c.support.DefaultLifecycleProcessor : Stopping beans in phase 2147483647 > 2016-06-14 14:34:57.447 WARN 5790 --- [enerContainer-1] o.s.j.l.DefaultMessageListenerContainer : Rejecting received message because of the listener container having been stopped in the meantime: ActiveMQMessage[ID:c88ada9c-3234-11e6-94cb-52540027ba72]:PERSISTENT/ClientMessage[messageID=7, durable=true, address=jms.queue.quickstart-messages,userID=c88ada9c-3234-11e6-94cb-52540027ba72,properties=TypedProperties[__AMQ_CID=c8897b08-3234-11e6-94cb-52540027ba72]] > 2016-06-14 14:34:57.456 INFO 5790 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Unregistering JMX-exposed beans on shutdown > 2016-06-14 14:34:57.466 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.2.0 [c852656c-3234-11e6-94cb-52540027ba72] stopped, uptime 1.275 seconds > 2016-06-14 14:34:57.469 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:57.470 INFO 5790 --- [ main] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed drop of schema as part of SessionFactory shut-down' > 2016-06-14 14:34:57.488 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032014: Stopping transaction recovery manager > " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) > at org.jboss.narayana.quickstart.spring.QuickstartApplicationTests.testCommit(QuickstartApplicationTests.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.springframework.boot.test.rule.OutputCapture$1.evaluate(OutputCapture.java:61) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2685: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:07 -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 updated JBTM-2678: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > @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 > Assignee: Gytis Trikleris > Fix For: 5.next > > > @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 (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2673) ThreadUtil getThreadId(Thread) ignores argument In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2673: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > ThreadUtil getThreadId(Thread) ignores argument > ----------------------------------------------- > > Key: JBTM-2673 > URL: https://issues.jboss.org/browse/JBTM-2673 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of https://developer.jboss.org/thread/269784?start=15&tstart=0 it was observed that the ThreadUtil implementation does not use the Thread argument and simply uses a ThreadLocal: > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/utils/ThreadUtil.java#L51 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2676: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2671: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > TXBridge quickstart execution steps are inaccurate > -------------------------------------------------- > > Key: JBTM-2671 > URL: https://issues.jboss.org/browse/JBTM-2671 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong. > We shouldn't suggest to start the container manually, but only use the managed container. > Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2669: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2662) Export org.jboss.tm, has 1, private references [org.jboss.logging] In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2662: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Export org.jboss.tm, has 1, private references [org.jboss.logging] > -------------------------------------------------------------------- > > Key: JBTM-2662 > URL: https://issues.jboss.org/browse/JBTM-2662 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2661) Unknown directive cardinality: in Require-Capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2661: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Unknown directive cardinality: in Require-Capability > ---------------------------------------------------- > > Key: JBTM-2661 > URL: https://issues.jboss.org/browse/JBTM-2661 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Unknown directive cardinality: in Require-Capability, allowed directives are effective:,resolution:,filter:, and 'x-*'. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover could return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > XATerminatorImple#recover could return an empty array in preference to null > --------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:09 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:09 -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 updated JBTM-2652: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > 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: Tom Jenkinson > Fix For: 5.next > > > Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2659) narayana-osgi-jta build bundle warings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2659: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > narayana-osgi-jta build bundle warings > -------------------------------------- > > Key: JBTM-2659 > URL: https://issues.jboss.org/browse/JBTM-2659 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > There are three warning when building the bundle. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:09 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2623: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:09 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2646: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:09 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2571: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:09 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2553: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:10 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2498: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:10 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2115: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:10 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:10 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:10 -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 updated JBTM-1107: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.next > > > *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 (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:11 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-223: ------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:09:10 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:09:10 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2480: -------------------------------- Fix Version/s: 5.next (was: 5.3.4.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:18:03 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 12 Aug 2016 09:18:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2731: ------------------------------------- Summary: Fix update_jira.py script Key: JBTM-2731 URL: https://issues.jboss.org/browse/JBTM-2731 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:19:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 12 Aug 2016 09:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2731: ------------------------------------- Assignee: Tom Jenkinson (was: Gytis Trikleris) > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1052 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:22:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:22:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2731: -------------------------------- Fix Version/s: 5.3.4.Final (was: 5.next) > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:26:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2731: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:26:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2731) Fix update_jira.py script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2731. ------------------------------- > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 09:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 09:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2732: ----------------------------------- Summary: pre-release.sh does not allow tagging to proceed when error does not exist Key: JBTM-2732 URL: https://issues.jboss.org/browse/JBTM-2732 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.3.4.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 10:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 10:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2732. --------------------------------- Resolution: Done > pre-release.sh does not allow tagging to proceed when error does not exist > -------------------------------------------------------------------------- > > Key: JBTM-2732 > URL: https://issues.jboss.org/browse/JBTM-2732 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 10:01:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 10:01:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2732. ------------------------------- > pre-release.sh does not allow tagging to proceed when error does not exist > -------------------------------------------------------------------------- > > Key: JBTM-2732 > URL: https://issues.jboss.org/browse/JBTM-2732 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 12 11:05:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 12 Aug 2016 11:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #9121 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 01:53:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 01:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2733: ------------------------------------- Summary: 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 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 (v6.4.11#64026) From issues at jboss.org Mon Aug 15 09:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 09:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2734: ------------------------------------- Summary: EIS can't recover transaction when heuristic outcome happens Key: JBTM-2734 URL: https://issues.jboss.org/browse/JBTM-2734 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Minor For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. # transaction is marked to have heuristic result and manual intervention is necessary # user calls {{recover}} for participant at such state and its state is changed to _prepared_ # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be # EIS propagates EIS TX to Narayana # enlisting XAR in Narayana subordinate TX # committing EIS TX ## It commits Narayana subordinate TX # XAR in Narayana TX returns RMERR # Narayana returns XA_HEURMIX # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet # EIS should call Narayana via XATerminator::recover() ## getting back an Xid that matches to Narayana subordinate TX # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 09:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 09:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2734: ---------------------------------- Component/s: JTA > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 09:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 09:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2734: ---------------------------------- Affects Version/s: 5.3.3.Final > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 09:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 09:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2734: ------------------------------------- Assignee: Tom Jenkinson > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 16:30:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 16:30:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2735: ------------------------------------- Summary: EIS can't finish all participants of inflow in-doubt transaction after jvm crash Key: JBTM-2735 URL: https://issues.jboss.org/browse/JBTM-2735 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? Expected flow of the case would be # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR # TM receives commit order by EIS RAR call {{XATerminator.commit}} # TM prepares both participants # end phase prepares, start phase commits # JVM crashes # app server is restarted again # EIS system repeats commit call as subordinate txn was not finished # TM calls commit on both participants to finish the transaction This scenario has two troubles in current implementation If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 16:30:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 16:30:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2735: ------------------------------------- Assignee: Tom Jenkinson > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 16:30:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 16:30:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2735: ---------------------------------- Affects Version/s: 5.3.3.Final > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 16:31:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 16:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2735: ---------------------------------- Component/s: JTA JTS > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 15 16:37:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 15 Aug 2016 16:37:00 -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 ] Ondra Chaloupka reassigned JBTM-2733: ------------------------------------- Assignee: 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: Tom Jenkinson > > 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 (v6.4.11#64026) From issues at jboss.org Tue Aug 16 05:20:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Aug 2016 05:20:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279489#comment-13279489 ] Tom Jenkinson commented on JBTM-2701: ------------------------------------- This was believed to be the cause of the SF ticket but actually it was JBTM-2614 > XAR should be scanned more frequently for prepared transactions > --------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 05:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Aug 2016 05:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2701: -------------------------------- Summary: Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system (was: XAR should be scanned more frequently for prepared transactions) > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 08:35:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 16 Aug 2016 08:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2736) Enhance error log message on long node name to contain max node name length In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2736: ------------------------------------- Summary: Enhance error log message on long node name to contain max node name length Key: JBTM-2736 URL: https://issues.jboss.org/browse/JBTM-2736 Project: JBoss Transaction Manager Issue Type: Enhancement Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor When maximal node identifier size is exceeded an exception and log message is shown. This message does not contain information what was the maximum of the node identifier length for user could easily adjust his setting based on that info. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 08:37:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 16 Aug 2016 08:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2736) Enhance error log message on long node name to contain max node name length In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2736: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1047 > Enhance error log message on long node name to contain max node name length > --------------------------------------------------------------------------- > > Key: JBTM-2736 > URL: https://issues.jboss.org/browse/JBTM-2736 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When maximal node identifier size is exceeded an exception and log message is shown. This message does not contain information what was the maximum of the node identifier length for user could easily adjust his setting based on that info. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:11:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 16 Aug 2016 09:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279666#comment-13279666 ] RH Bugzilla Integration commented on JBTM-2720: ----------------------------------------------- Petr Jurak changed the Status of [bug 1367187|https://bugzilla.redhat.com/show_bug.cgi?id=1367187] from NEW to ASSIGNED > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:15:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Aug 2016 09:15:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2736) Enhance error log message on long node name to contain max node name length In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2736: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Enhance error log message on long node name to contain max node name length > --------------------------------------------------------------------------- > > Key: JBTM-2736 > URL: https://issues.jboss.org/browse/JBTM-2736 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When maximal node identifier size is exceeded an exception and log message is shown. This message does not contain information what was the maximum of the node identifier length for user could easily adjust his setting based on that info. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:16:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Aug 2016 09:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2730: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:16:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Aug 2016 09:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2720: --------------------------------- > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:16:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Aug 2016 09:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2720: -------------------------------- Fix Version/s: 4.17.35 > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 09:18:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Aug 2016 09:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1053 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 16 16:03:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 16 Aug 2016 16:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13279927#comment-13279927 ] RH Bugzilla Integration commented on JBTM-2720: ----------------------------------------------- Brad Maxwell changed the Status of [bug 1367187|https://bugzilla.redhat.com/show_bug.cgi?id=1367187] from ASSIGNED to POST > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 01:24:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 17 Aug 2016 01:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1056 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade the apr to 1.5 > ---------------------- > > Key: JBTM-2723 > URL: https://issues.jboss.org/browse/JBTM-2723 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 06:45:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 17 Aug 2016 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2685: -------------------------------- Priority: Critical (was: Major) > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 06:47:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Aug 2016 06:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280152#comment-13280152 ] Michael Musgrove commented on JBTM-2685: ---------------------------------------- We are currently blocked by https://issues.apache.org/jira/browse/SUREFIRE-1265 > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 06:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Aug 2016 06:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280160#comment-13280160 ] Michael Musgrove commented on JBTM-2685: ---------------------------------------- And the intended initial set of tests to run with the JDK 9 jvm are as follows (please refer to our CI run script in the master or branch git repo, scripts/hudson/narayana.sh, to see which specific tests each switch runs): BLACKTIE=0 JTA_AS_TESTS=0 XTS_AS_TESTS=0 RTS_AS_TESTS=0 QA_TESTS=0 PERF_TESTS=0 NARAYANA_TESTS=1 TXF_TESTS=1 OSGI_TESTS=1 JTA_CDI_TESTS=1 XTS_TESTS=1 txbridge=1 RTS_TESTS=1 > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 07:13:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Aug 2016 07:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2685: ----------------------------------- Comment: was deleted (was: We are currently blocked by https://issues.apache.org/jira/browse/SUREFIRE-1265 ) > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 09:12:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Aug 2016 09:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2449) SPI class ServerVMClientUserTransaction should be Serializable and Referenceable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2449: ------------------------------------ ServerVMClientUserTransaction is still not fully serializable > SPI class ServerVMClientUserTransaction should be Serializable and Referenceable > -------------------------------------------------------------------------------- > > Key: JBTM-2449 > URL: https://issues.jboss.org/browse/JBTM-2449 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: SPI > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > This SPI class implements UserTransaction but does not follow the JNDI conventions. The JTA specification (section 3.1) says: > bq. The implementation of the UserTransaction object must be both javax.naming.Referenceable and java.io.Serializable , so that the object can be stored in all JNDI naming contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 17 10:24:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 17 Aug 2016 10:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280313#comment-13280313 ] RH Bugzilla Integration commented on JBTM-2614: ----------------------------------------------- Radovan STANCEL changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from NEW to ASSIGNED > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.35, 5.2.13.Final > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 18 04:17:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 18 Aug 2016 04:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280569#comment-13280569 ] RH Bugzilla Integration commented on JBTM-2614: ----------------------------------------------- Radovan STANCEL changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from ASSIGNED to POST > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.35, 5.2.13.Final > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 18 09:23:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 18 Aug 2016 09:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2449) SPI class ServerVMClientUserTransaction should be Serializable and Referenceable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #12 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > SPI class ServerVMClientUserTransaction should be Serializable and Referenceable > -------------------------------------------------------------------------------- > > Key: JBTM-2449 > URL: https://issues.jboss.org/browse/JBTM-2449 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: SPI > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > This SPI class implements UserTransaction but does not follow the JNDI conventions. The JTA specification (section 3.1) says: > bq. The implementation of the UserTransaction object must be both javax.naming.Referenceable and java.io.Serializable , so that the object can be stored in all JNDI naming contexts. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 02:30:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 22 Aug 2016 02:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2723: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade the apr to 1.5 > ---------------------- > > Key: JBTM-2723 > URL: https://issues.jboss.org/browse/JBTM-2723 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 02:32:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 22 Aug 2016 02:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2737) Karaf build fail In-Reply-To: References: Message-ID: Amos Feng created JBTM-2737: ------------------------------- Summary: Karaf build fail Key: JBTM-2737 URL: https://issues.jboss.org/browse/JBTM-2737 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Reporter: Amos Feng Assignee: Amos Feng [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project static: Unable to build assembly: Error downloading configuration files. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 04:09:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 22 Aug 2016 04:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2737) Karaf build fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281832#comment-13281832 ] Amos Feng commented on JBTM-2737: --------------------------------- It looks like the upstream issue and now it is back to work http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-quickstarts/382/ > Karaf build fail > ---------------- > > Key: JBTM-2737 > URL: https://issues.jboss.org/browse/JBTM-2737 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project static: Unable to build assembly: Error downloading configuration files. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 04:13:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 22 Aug 2016 04:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2737) Karaf build fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2737. ----------------------------- Resolution: Out of Date > Karaf build fail > ---------------- > > Key: JBTM-2737 > URL: https://issues.jboss.org/browse/JBTM-2737 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > > [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.1.0-SNAPSHOT:assembly (process-resources) on project static: Unable to build assembly: Error downloading configuration files. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 04:23:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 04:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2726: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Replace deprecated OutputCapture in Spring Boot quickstart test > --------------------------------------------------------------- > > Key: JBTM-2726 > URL: https://issues.jboss.org/browse/JBTM-2726 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 05:45:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #50 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 06:08:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 06:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #174 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > TXBridge quickstart execution steps are inaccurate > -------------------------------------------------- > > Key: JBTM-2671 > URL: https://issues.jboss.org/browse/JBTM-2671 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong. > We shouldn't suggest to start the container manually, but only use the managed container. > Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 07:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2734: -------------------------------- Priority: Critical (was: Minor) > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 07:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2735: -------------------------------- Priority: Critical (was: Major) > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 07:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2734: -------------------------------- Fix Version/s: 5.next > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 07:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2735: -------------------------------- Fix Version/s: 5.next > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:48:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 22 Aug 2016 07:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2738) Upgrade jboss-transaction-spi dependency to 7.3.3.Final In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2738: -------------------------------------- Summary: Upgrade jboss-transaction-spi dependency to 7.3.3.Final Key: JBTM-2738 URL: https://issues.jboss.org/browse/JBTM-2738 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.next There is a new version of the jboss-transaction-spi which fixed a UserTransaction serialization issue. This change should not affect narayana (hence the minor priority leve) but we should be consuming the most recent release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 07:56:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 22 Aug 2016 07:56:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2739) Add a CI job for testing jboss-transaction-spi In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2739: -------------------------------------- Summary: Add a CI job for testing jboss-transaction-spi Key: JBTM-2739 URL: https://issues.jboss.org/browse/JBTM-2739 Project: JBoss Transaction Manager Issue Type: Task Components: SPI Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next We need a CI job to test that narayana works with the latest jboss-transaction-spi and this should include PRs as well as master. In addition, the two projects duplicate tests so the the duplicates need removing from narayana (but only after we have added this CI testing). Note that jboss-transaction-spi has a test dependency on the last released stable version of narayana so that dependency would need to changed to the version of our current SNAPSHOT for these new proposed CI jobs to be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 08:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 08:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282017#comment-13282017 ] Tom Jenkinson commented on JBTM-2735: ------------------------------------- Please can you provide a link in the reproducer to the repo where the test is? > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 08:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Aug 2016 08:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282018#comment-13282018 ] Tom Jenkinson commented on JBTM-2734: ------------------------------------- Please can you provide a link in the reproducer to the repo where the test is? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 08:57:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 22 Aug 2016 08:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2740) Make the quickstart CI narayana.sh run script work on both clusters In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2740: -------------------------------------- Summary: Make the quickstart CI narayana.sh run script work on both clusters Key: JBTM-2740 URL: https://issues.jboss.org/browse/JBTM-2740 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.next The script does not run on the NCL cluster most likely due to hard coded paths. Fixing this will be useful because the current config hard codes which set of quickstarts to run (which is not maintainable as we add and remove quickstarts). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:04:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282061#comment-13282061 ] Gytis Trikleris commented on JBTM-2334: --------------------------------------- I'm assigning this to myself, because it's needed for using Narayana with BxMS on Tomcat. > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.4 > Reporter: Mark Little > > It's still too difficult for people to do. > http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-transaction-manager-with -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:04:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2334: ------------------------------------- Assignee: Gytis Trikleris > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Affects Versions: 5.0.4 > Reporter: Mark Little > Assignee: Gytis Trikleris > > It's still too difficult for people to do. > http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-transaction-manager-with -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:05:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2334: ---------------------------------- Fix Version/s: 5.next > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > It's still too difficult for people to do. > http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-transaction-manager-with -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:05:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2334: ---------------------------------- Affects Version/s: (was: 5.0.4) > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > It's still too difficult for people to do. > http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-transaction-manager-with -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:06:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2334: ---------------------------------- Description: Initial requirements: # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional) # Implement Tomcat lifecycle listener to bootstrap TM and RM # Provide custom Narayana configuration file for Tomcat # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry # Add pooling to transactional driver (either implement it or use some library) was: It's still too difficult for people to do. http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-transaction-manager-with > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initial requirements: > # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional) > # Implement Tomcat lifecycle listener to bootstrap TM and RM > # Provide custom Narayana configuration file for Tomcat > # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry > # Add pooling to transactional driver (either implement it or use some library) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:09:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2671: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > TXBridge quickstart execution steps are inaccurate > -------------------------------------------------- > > Key: JBTM-2671 > URL: https://issues.jboss.org/browse/JBTM-2671 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong. > We shouldn't suggest to start the container manually, but only use the managed container. > Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:28:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:28:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2669: ---------------------------------- Issue Type: Task (was: Bug) > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 22 09:40:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Aug 2016 09:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2669: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 23 04:31:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Aug 2016 04:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2734: ---------------------------------- Steps to Reproduce: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery {code} was: Crashrecovery testsuite could be used for reproducing the issue mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 23 04:31:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Aug 2016 04:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2735: ---------------------------------- Steps to Reproduce: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery#jvmCrashAfterPrepare {code} was: Crashrecovery testsuite could be used for reproducing the issue {code} mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery#jvmCrashAfterPrepare {code} > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 23 04:31:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Aug 2016 04:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282469#comment-13282469 ] Ondra Chaloupka commented on JBTM-2735: --------------------------------------- The reproducer is under master branch of repo {{http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git}}. > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 23 04:31:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Aug 2016 04:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13282470#comment-13282470 ] Ondra Chaloupka commented on JBTM-2734: --------------------------------------- The reproducer is under master branch of repo {{http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git}}. > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 08:21:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 08:21:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2741: ------------------------------------- Summary: Losing message during inflow transaction processing Key: JBTM-2741 URL: https://issues.jboss.org/browse/JBTM-2741 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. This is the scenario which behaves wrong by my view * EIS passes a message with xid1 to RAR to be processed * first message is passed as work to be process (stays in progress) * EIS passes a second message with xid1 to RAR to be processed * the second message is forgotten. It will never reach a {{MessageListner}} ** no error is returned or shown in log Compared following scenario passes without a problem. * EIS passes a message with xid1 to RAR to be processed * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) * EIS passes a second message with xid1 to RAR to be processed * second message is processed by {{MessageListener}} By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 08:21:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 08:21:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2741: ------------------------------------- Assignee: Tom Jenkinson > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 08:21:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 08:21:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2741: ---------------------------------- Affects Version/s: 5.3.3.Final > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 08:22:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 08:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2741: ---------------------------------- Component/s: JTA JTS > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 08:55:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Aug 2016 08:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2741: -------------------------------- Component/s: JCA > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 09:05:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Aug 2016 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283643#comment-13283643 ] Tom Jenkinson commented on JBTM-2741: ------------------------------------- Please can you attach a log? What makes you think Narayana was involved? You look to be sending messages directly to your RAR? > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 09:38:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 09:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2741: ---------------------------------- Attachment: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 09:48:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 09:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283690#comment-13283690 ] Ondra Chaloupka commented on JBTM-2741: --------------------------------------- Log attached. My observation of this could be trouble at Narayana side came from comment here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TxWorkManager.java#L73 but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :) > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 09:49:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 09:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) Losing message during inflow transaction processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283690#comment-13283690 ] Ondra Chaloupka edited comment on JBTM-2741 at 8/24/16 9:48 AM: ---------------------------------------------------------------- Log attached. My observation of this could be trouble at Narayana side came from comment here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TxWorkManager.java#L73 but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :) ) was (Author: ochaloup): Log attached. My observation of this could be trouble at Narayana side came from comment here https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TxWorkManager.java#L73 but I have to admit that I haven't tried to debug it to this level. Give me some time to check how jca logging output looks. I'll be back soon (I hope :) > Losing message during inflow transaction processing > --------------------------------------------------- > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 10:17:00 2016 From: issues at jboss.org (Johnathon Lee (JIRA)) Date: Wed, 24 Aug 2016 10:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2742) XTS and HA-Cluster combatibility In-Reply-To: References: Message-ID: Johnathon Lee created JBTM-2742: ----------------------------------- Summary: XTS and HA-Cluster combatibility Key: JBTM-2742 URL: https://issues.jboss.org/browse/JBTM-2742 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTA, JTS Reporter: Johnathon Lee The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment. Currently, the XTS subsystem is not compatible in a clustered EAP deployment. For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 10:23:00 2016 From: issues at jboss.org (Jonathan Halliday (JIRA)) Date: Wed, 24 Aug 2016 10:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2742) XTS and HA-Cluster combatibility In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Halliday updated JBTM-2742: ------------------------------------ Component/s: XTS (was: JTA) (was: JTS) > XTS and HA-Cluster combatibility > -------------------------------- > > Key: JBTM-2742 > URL: https://issues.jboss.org/browse/JBTM-2742 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Reporter: Johnathon Lee > > The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment. > Currently, the XTS subsystem is not compatible in a clustered EAP deployment. > For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 10:28:01 2016 From: issues at jboss.org (Johnathon Lee (JIRA)) Date: Wed, 24 Aug 2016 10:28:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2742) XTS and HA-Cluster compatibility In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnathon Lee updated JBTM-2742: -------------------------------- Summary: XTS and HA-Cluster compatibility (was: XTS and HA-Cluster combatibility) > XTS and HA-Cluster compatibility > -------------------------------- > > Key: JBTM-2742 > URL: https://issues.jboss.org/browse/JBTM-2742 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Reporter: Johnathon Lee > > The request here would be to enable compatibility between the XTS subsystem and a clustered EAP deployment. > Currently, the XTS subsystem is not compatible in a clustered EAP deployment. > For this configuration to work, the clustered environment cluster traffic routing layer would need to be transactionally aware, such that routing could be based upon a transaction id (txid) rather than session information. Alternatively, the XTS subsystem would need to be adapted to preserve the transport (http) layer's session cookie information and the session cookie information be passed or persisted whenever the coordinator/participant url is used (which has potential specification level issues). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 11:43:00 2016 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 24 Aug 2016 11:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski updated JBTM-2725: --------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 14:07:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Aug 2016 14:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283887#comment-13283887 ] Tom Jenkinson commented on JBTM-2734: ------------------------------------- You are not calling XATerminator::recover() - this will reinitialize the Subordinate Transactions. However - I do believe there is still a bug in Narayana in that we should be removing the reference to the transaction when we see the Heuristic. i.e above: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L131 add: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L149 If you can change your test to call XATerminator::recover() before retrying the commits I will test my patch here. Many thanks! > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 24 15:42:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Aug 2016 15:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2741) No error message on concurrent processing of the same inflow transaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2741: ---------------------------------- Summary: No error message on concurrent processing of the same inflow transaction (was: Losing message during inflow transaction processing) > No error message on concurrent processing of the same inflow transaction > ------------------------------------------------------------------------ > > Key: JBTM-2741 > URL: https://issues.jboss.org/browse/JBTM-2741 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Attachments: JcaInflowTransactionTestCase_multipleWorkSharedXidInBunch_jta_server.log > > > I experience losing messages when they are received with the same xid when messages are received in parallel. This means case that prior message is not yet fully processed when meanwhile new message is promoted for being processed. > This is the scenario which behaves wrong by my view > * EIS passes a message with xid1 to RAR to be processed > * first message is passed as work to be process (stays in progress) > * EIS passes a second message with xid1 to RAR to be processed > * the second message is forgotten. It will never reach a {{MessageListner}} > ** no error is returned or shown in log > Compared following scenario passes without a problem. > * EIS passes a message with xid1 to RAR to be processed > * first message is fully processed with {{MessageListner}} (it reaches the end of the _onMessage_ method) > * EIS passes a second message with xid1 to RAR to be processed > * second message is processed by {{MessageListener}} > By reading jca spec and description of JBTM-2164 I do understand that several messages could be passed with the same xid in parrarel. If my interpretation or scenario setup is wrong, please, let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 04:52:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 04:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1059 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 04:57:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 04:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284058#comment-13284058 ] Ondra Chaloupka commented on JBTM-2734: --------------------------------------- Hi Tom, I added a call for RAR process {{XATerminator.recover()}} call as you suggested. The current procedure is [1]: * recover participant by jboss cli call * call {{XATerminator.recover()}} * having one round of periodic transaction recovery being processed If you have other remarks to the test scenario I would be glad to hear them. Thanks. [1] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java;h=e20407ed6410d9a6f2368b280be965bcc4201953;hb=master#l535 > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 04:58:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 04:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284058#comment-13284058 ] Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 4:57 AM: ---------------------------------------------------------------- Hi Tom, I added a command for RAR to process {{XATerminator.recover()}} call as you suggested. The current procedure is [1]: * recover participant by jboss cli call * call {{XATerminator.recover()}} * having one round of periodic transaction recovery being processed If you have other remarks to the test scenario I would be glad to hear them. Thanks. [1] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java;h=e20407ed6410d9a6f2368b280be965bcc4201953;hb=master#l535 was (Author: ochaloup): Hi Tom, I added a call for RAR process {{XATerminator.recover()}} call as you suggested. The current procedure is [1]: * recover participant by jboss cli call * call {{XATerminator.recover()}} * having one round of periodic transaction recovery being processed If you have other remarks to the test scenario I would be glad to hear them. Thanks. [1] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java;h=e20407ed6410d9a6f2368b280be965bcc4201953;hb=master#l535 > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:00:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 05:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284062#comment-13284062 ] Tom Jenkinson commented on JBTM-2734: ------------------------------------- Added a pull but need to add a unit test still. Your test will need changing to call a new method "sendRecover();" on line 542 before the commit that is expected to work. Until then it will use the previous heuristic state. > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:07:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284065#comment-13284065 ] Ondra Chaloupka commented on JBTM-2734: --------------------------------------- ok, so the recover process needs to be like this? * recover participant by jboss cli call * call XATerminator.recover() * having one round of periodic transaction recovery being processed * XATerminator.recover() * call commit or do I need to have a periodic recovery here? Would be enough to _recover participant - recover - commit_? If I understood you previous comment correctly - what if user calls _recover participant - recover_ then he has a pause while periodic recovery is processed and then he wants to _commit_. Will this fail as he need to call recovery right before commit is done? This would not be much well-suited, wouldn't it? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:08:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284065#comment-13284065 ] Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 5:07 AM: ---------------------------------------------------------------- ok, so the recover process needs to be like this? * recover participant by jboss cli call * call XATerminator.recover() * having one round of periodic transaction recovery being processed * XATerminator.recover() * call commit or do I need to have a periodic recovery here? Would be enough to _recover participant - recover - commit_? If I understood you previous comment correctly - what if user calls _recover participant - recover_ then he has a pause while periodic recovery is processed and then he wants to _commit_. Will this fail as he need to call XATerminator.recovery right before commit is done? This would not be much well-suited, wouldn't it? was (Author: ochaloup): ok, so the recover process needs to be like this? * recover participant by jboss cli call * call XATerminator.recover() * having one round of periodic transaction recovery being processed * XATerminator.recover() * call commit or do I need to have a periodic recovery here? Would be enough to _recover participant - recover - commit_? If I understood you previous comment correctly - what if user calls _recover participant - recover_ then he has a pause while periodic recovery is processed and then he wants to _commit_. Will this fail as he need to call recovery right before commit is done? This would not be much well-suited, wouldn't it? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:08:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284065#comment-13284065 ] Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 5:07 AM: ---------------------------------------------------------------- ok, so the recover process needs to be like this? * recover participant by jboss cli call * call XATerminator.recover() * having one round of periodic transaction recovery being processed * XATerminator.recover() * call commit or do I need to have a periodic recovery here? Would be enough to _recover participant - recover - commit_? If I understood you previous comment correctly - what if user calls _recover participant - recover_ then he has a pause while periodic recovery is processed and then he wants to _commit_. Will this fail as he need to call XATerminator.recover right before commit is done? This would not be much well-suited, wouldn't it? was (Author: ochaloup): ok, so the recover process needs to be like this? * recover participant by jboss cli call * call XATerminator.recover() * having one round of periodic transaction recovery being processed * XATerminator.recover() * call commit or do I need to have a periodic recovery here? Would be enough to _recover participant - recover - commit_? If I understood you previous comment correctly - what if user calls _recover participant - recover_ then he has a pause while periodic recovery is processed and then he wants to _commit_. Will this fail as he need to call XATerminator.recovery right before commit is done? This would not be much well-suited, wouldn't it? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:10:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 05:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284066#comment-13284066 ] Tom Jenkinson commented on JBTM-2734: ------------------------------------- Wait sorry, I think we had overlapping comments... > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284079#comment-13284079 ] Ondra Chaloupka commented on JBTM-2734: --------------------------------------- Ah, ok, I see now. > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284079#comment-13284079 ] Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 5:25 AM: ---------------------------------------------------------------- Ah, ok, I can see now. was (Author: ochaloup): Ah, ok, I see now. > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 05:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284082#comment-13284082 ] Tom Jenkinson commented on JBTM-2734: ------------------------------------- Your change was the one I said it might have seemed confusing to come so shortly after you said what you were doing :) What I can say though is that you will leave the XATerminator in a funny state at the moment because you are just using TMSTARTRSCAN You really need: sendRecover(TMSTARTRSCAN) sendCommit(xid) sendRecover(TMENDRSCAN) > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:41:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:41:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284093#comment-13284093 ] Ondra Chaloupka commented on JBTM-2734: --------------------------------------- Thanks for the note. _ leaving the XATerminator in a funny state_ made my day ;) I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to: * sendRecover(TMSTARTRSCAN) * sendRecover(TMENDRSCAN) * sendCommit(xid) would you consider that correct? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:42:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 05:42:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284095#comment-13284095 ] Tom Jenkinson commented on JBTM-2735: ------------------------------------- I am trying to run this test but it won't reboot the server: {quote} Running org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.94 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 20.748 sec <<< ERROR! org.jboss.arquillian.container.spi.client.container.LifecycleException: The java process starting the managed server exited unexpectedly with code [1] at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:152) at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:115) at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.start(ClientContainerController.java:150) at org.jboss.as.test.jbossts.base.TestBaseOneServer.rebootServer(TestBaseOneServer.java:345) at org.jboss.as.test.jbossts.base.TestBaseOneServer.rebootServer(TestBaseOneServer.java:314) at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepare(JcaInflowTransactionTestCase.java:611) jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 20.748 sec <<< ERROR! java.lang.IllegalArgumentException: Deployment with name mock-resource-adapter-test could not be undeployed. Container jbossts must be still running. at org.jboss.arquillian.container.test.impl.client.deployment.ClientDeployer.undeploy(ClientDeployer.java:129) at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.doUndeploy(JcaInflowTransactionTestCase.java:201) Results : Tests in error: org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepare(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Run 1: JcaInflowTransactionTestCase.jvmCrashAfterPrepare:611->TestBaseOneServer.rebootServer:314->TestBaseOneServer.rebootServer:345 ? Lifecycle Run 2: JcaInflowTransactionTestCase>TestBaseOneServer.after:260->doUndeploy:201 ? IllegalArgument {quote} > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 05:42:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 05:42:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284093#comment-13284093 ] Ondra Chaloupka edited comment on JBTM-2734 at 8/25/16 5:41 AM: ---------------------------------------------------------------- Thanks for the note. _leaving the XATerminator in a funny state_ made my day ;) I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to: * sendRecover(TMSTARTRSCAN) * sendRecover(TMENDRSCAN) * sendCommit(xid) would you consider that correct? was (Author: ochaloup): Thanks for the note. _ leaving the XATerminator in a funny state_ made my day ;) I've already found that when you mentioned that there is a need for {{XATerminator.recover call}}. I changed it to: * sendRecover(TMSTARTRSCAN) * sendRecover(TMENDRSCAN) * sendCommit(xid) would you consider that correct? > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 06:28:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2735: ---------------------------------- Steps to Reproduce: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare {code} was: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery#jvmCrashAfterPrepare {code} > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 06:29:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 06:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2735: ---------------------------------- Steps to Reproduce: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare {code} was: Crashrecovery testsuite could be used for reproducing the issue {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JcaInflowTransactionTestCase#jvmCrashAfterPrepare {code} > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 06:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 06:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2720: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 06:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 06:31:00 -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:comment-tabpanel&focusedCommentId=13284121#comment-13284121 ] Tom Jenkinson commented on JBTM-2733: ------------------------------------- Must state that for recovery to work (especially after using tooling to reset a heuristic) the EIS is expected to follow XA and call xa_recover(START), xa_commit/rb, xa_recover(END) > 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: Tom Jenkinson > > 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 (v6.4.11#64026) From issues at jboss.org Thu Aug 25 06:32:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 06:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284122#comment-13284122 ] Tom Jenkinson commented on JBTM-2735: ------------------------------------- The clue was in the fact you needed the recovery call first. I suspect this is caused by JBTM-2701. I would say that even when I hold it in the debugger long enough for recovery to happen the test does still fail with: instrumentedTestXAResource.assertKnownInstances(2); However I see from the log that the Xid was committed twice so I think that aspect may be a test issue. I will work on 2701 first. > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 09:47:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 09:47:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284257#comment-13284257 ] Tom Jenkinson commented on JBTM-2701: ------------------------------------- Noted that work in this area carried out before as part of JBTM-1354 > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 09:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 09:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1060 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 09:53:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 09:53:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284263#comment-13284263 ] Tom Jenkinson commented on JBTM-2735: ------------------------------------- I created a pull on JBTM-2701 https://github.com/jbosstm/narayana/pull/1060 - it seems to make your test pass too. However, I think there is an issue with the test which I fixed as follows. {quote} [tom at wicket eap-tests-transactions](master)(14:51:41) $ git diff jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java diff --git a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java index e20407e..9aa6dfc 100644 --- a/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java +++ b/jbossts/src/test/java/org/jboss/as/test/jbossts/crashrec/jca/test/JcaInflowTransactionTestCase.java @@ -581,7 +581,7 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer { * TODO: it's expected this test will need to be tuned after discussion on raised jira */ @Test - @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow in-doubt transaction after jvm crash") +// @Ignore("JBEAP-5641/JBTM-2735: EIS can't finish all participants of inflow in-doubt transaction after jvm crash") public void jvmCrashAfterPrepare() throws Throwable { JBossLogParserSetup.addSkipPatternForTest(".*XAER_RMFAIL.*", ".*javax.transaction.xa.XAException.*"); @@ -620,16 +620,16 @@ public class JcaInflowTransactionTestCase extends TestBaseOneServer { // I think yes, as for EIS the transaction managed by app server TM is in fact one participant Assert.assertEquals("One xid should be returned", "1", numberOfXids.get()); - doRecovery(); +// doRecovery(); // the participant was recovered -> it's in prepare state - let's commit it sendCommit(xidNumId); // xa resource should be committed - instrumentedTestXAResource.assertKnownInstances(2); + instrumentedTestXAResource.assertKnownInstances(1); instrumentedTestXAResource.assertMethodNotCalled("rollback"); instrumentedTestXAResource.assertMethodNotCalled("prepare"); - instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources should be committed", "commit", 1); + instrumentedTestXAResource.assertMethodCallCount("Both two TestXAResources should be committed", "commit", 2); // and logs should be empty (even jboss cli should say so) TMOperations ops = ManagementClientSetup.getTMOperations(TestProperties.CRASHREC_CONTAINER); {quote} > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 10:17:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Aug 2016 10:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2720: -------------------------------- Fix Version/s: 5.2.18.Final > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.2.18.Final, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Aug 25 12:02:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 25 Aug 2016 12:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka closed JBTM-2735. --------------------------------- Resolution: Rejected Thanks Tom for investigation and help. Confirming this is a test issue as our test framework does not work correctly with multiple TestXAResources. I'm sorry for inconveniences. > EIS can't finish all participants of inflow in-doubt transaction after jvm crash > -------------------------------------------------------------------------------- > > Key: JBTM-2735 > URL: https://issues.jboss.org/browse/JBTM-2735 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.??? > Expected flow of the case would be > # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR > # TM receives commit order by EIS RAR call {{XATerminator.commit}} > # TM prepares both participants > # end phase prepares, start phase commits > # JVM crashes > # app server is restarted again > # EIS system repeats commit call as subordinate txn was not finished > # TM calls commit on both participants to finish the transaction > This scenario has two troubles in current implementation > If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called. > For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling. > (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 04:39:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 26 Aug 2016 04:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284616#comment-13284616 ] Michael Musgrove commented on JBTM-2725: ---------------------------------------- See the linked PR for the actual fix which was to return success from a rollback attempt if the transaction was already in any of the states ABORTED, ABORTING or H_ROLLBACK. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:11:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284640#comment-13284640 ] Tom Jenkinson commented on JBTM-2725: ------------------------------------- This was to match its behaviour with the standard local JTA variant. > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:11:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 26 Aug 2016 05:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2334 started by Gytis Trikleris. --------------------------------------------- > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initial requirements: > # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional) > # Implement Tomcat lifecycle listener to bootstrap TM and RM > # Provide custom Narayana configuration file for Tomcat > # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry > # Add pooling to transactional driver (either implement it or use some library) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:11:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:11:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2725: -------------------------------- Forum Reference: https://developer.jboss.org/thread/271935 > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.next > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:29:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:29:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2717: ----------------------------------- Assignee: Michael Musgrove > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:29:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:29:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2717: ----------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:37:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2717. --------------------------------- Fix Version/s: (was: 5.next) Resolution: Won't Fix This seems like a test issue. I had a look at the test and but a break point here: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/recovery/XARecoveryModuleHelpersUnitTest.java#L264 The issue is that the removal of the helper and the subsequent checking of the getScanState its not atomic so it can give erroneous responses. > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:39:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2717) XAResourceRecoveryHelper removed in a wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284657#comment-13284657 ] Tom Jenkinson commented on JBTM-2717: ------------------------------------- Also note that the test failed on slow (coverage) run > XAResourceRecoveryHelper removed in a wrong state > ------------------------------------------------- > > Key: JBTM-2717 > URL: https://issues.jboss.org/browse/JBTM-2717 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > > {code} > Failed tests: > XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval1:55->testTimelyXAResourceRecoveryHelperRemoval:208 helper removed in wrong state expected:<2> but was:<0> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284659#comment-13284659 ] Tom Jenkinson commented on JBTM-2732: ------------------------------------- The issue was in the script that we use for release. This is ancillary to the main project. > pre-release.sh does not allow tagging to proceed when error does not exist > -------------------------------------------------------------------------- > > Key: JBTM-2732 > URL: https://issues.jboss.org/browse/JBTM-2732 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:48:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2730: -------------------------------- Fix Version/s: 5.next > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2729) Upgrade the zip to 3.0 in the CI el5 servers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284660#comment-13284660 ] Tom Jenkinson commented on JBTM-2729: ------------------------------------- This is just an upload on the CI servers - ancillary to main project. > Upgrade the zip to 3.0 in the CI el5 servers > -------------------------------------------- > > Key: JBTM-2729 > URL: https://issues.jboss.org/browse/JBTM-2729 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2723: -------------------------------- Description: This is to provide the basis of JBTM-2719. APR now provides a method to wakeup waiting pools which should be useful. > Upgrade the apr to 1.5 > ---------------------- > > Key: JBTM-2723 > URL: https://issues.jboss.org/browse/JBTM-2723 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > This is to provide the basis of JBTM-2719. APR now provides a method to wakeup waiting pools which should be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:52:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:52:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2722: -------------------------------- Forum Reference: https://developer.jboss.org/message/956793#956793 > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.4.Final > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:52:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:52:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2722: --------------------------------- > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.4.Final > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:52:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:52:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2722. ------------------------------- Resolution: Done > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.4.Final > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:56:00 -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: -------------------------------- Summary: Investigate why a null FileLock is declared but not used (was: Remove FileLock cruft from LogStore file) > 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: Task > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > It certainly isn't referenced: > 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 (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:57:00 -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: -------------------------------- Description: 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 was: It certainly isn't referenced: https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce12e784fb6/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java#L734 > 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: Task > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > 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 (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2712: --------------------------------- > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Aug 26 05:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Aug 2016 05:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2712) Karaf build failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2712. ------------------------------- Resolution: Out of Date > Karaf build failing > ------------------- > > Key: JBTM-2712 > URL: https://issues.jboss.org/browse/JBTM-2712 > Project: JBoss Transaction Manager > Issue Type: Task > Components: OSGi > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > > The build of Karaf has started failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Aug 28 05:59:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 28 Aug 2016 05:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2734: -------------------------------- Summary: EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared (was: EIS can't recover transaction when heuristic outcome happens) > EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 29 03:19:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Aug 2016 03:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: Amos Feng created JBTM-2743: ------------------------------- Summary: Blacktie integration-tests TestTPCancel hang Key: JBTM-2743 URL: https://issues.jboss.org/browse/JBTM-2743 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 29 22:23:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Aug 2016 22:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285674#comment-13285674 ] Amos Feng commented on JBTM-2743: --------------------------------- the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fca0-4d3c-9884-1a38ce27ae90/wsapoll-and-nonblocking-connects-to-nonexistent-ports?forum=wsk > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Aug 29 22:33:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Aug 2016 22:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285674#comment-13285674 ] Amos Feng edited comment on JBTM-2743 at 8/29/16 10:32 PM: ----------------------------------------------------------- the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. [1] https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fca0-4d3c-9884-1a38ce27ae90/wsapoll-and-nonblocking-connects-to-nonexistent-ports?forum=wsk [2] http://stackoverflow.com/questions/21653003/is-this-wsapoll-bug-for-non-blocking-sockets-fixed was (Author: zhfeng): the apr_pollset_poll uses the WSAPoll as the default implementation since 1.4 And there was a bug in the WSAPoll when using the non-blocking connecting to the non-exist port. It never returns the failure. https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/18769abd-fca0-4d3c-9884-1a38ce27ae90/wsapoll-and-nonblocking-connects-to-nonexistent-ports?forum=wsk > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 06:50:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 30 Aug 2016 06:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266116#comment-13266116 ] Tom Jenkinson edited comment on JBTM-2701 at 8/30/16 6:49 AM: -------------------------------------------------------------- Problem is observed in following scenario: {code} 0. crash 1. Periodic recovery periodicFirstPass (before XAR1 registered with recovery system) - move from IDLE to BETWEEN_PASSES 2. XATerminator::recover() - loads SAA from external to PeriodicRecovery system 3. commit SAA1 4. commit XAResourceRecord1 5. XARecoveryModule::getNewXAResource 6. periodicFirstPass not called as not IDLE so no scan XAR1 so XAR unavailable {code} We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass. was (Author: tomjenkinson): Problem is observed in following scenario: {code} 0. prepare SAA1 1. prepare XAR1 2. getNewXAResource 3. periodicFirstPass (scans XAR1) - move from IDLE to BETWEEN_PASSES 4. commit XAR1 5. prepare XAR2 6. commit XAR2 7. getNewXAResource 8. periodicFirstPass not called as not IDLE so no scan XAR2 {code} We need to recall periodicFirstPass unless it is in the middle of secondpass, in which case we wait till that finishes then call it again. To allow multiple calls of first pass we need to detect the situation and ENDRSCAN outstanding ones as that is normally done in secondpass. > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 10:33:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 30 Aug 2016 10:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2734: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 11:40:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 11:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1062 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: win > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 11:40:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 11:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2743: ---------------------------- Labels: win (was: ) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: win > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 11:41:03 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 11:41:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2743: ---------------------------- Labels: (was: win) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 11:42:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 11:42:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2743: ---------------------------- Labels: vc9x32 (was: ) > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: vc9x32 > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:20:02 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:20:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2744) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: Amos Feng created JBTM-2744: ------------------------------- Summary: Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI Key: JBTM-2744 URL: https://issues.jboss.org/browse/JBTM-2744 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Priority: Minor Fix For: 5.next The warning message are {code} 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:21:01 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:21:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2745) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: Amos Feng created JBTM-2745: ------------------------------- Summary: Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI Key: JBTM-2745 URL: https://issues.jboss.org/browse/JBTM-2745 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The warning messages {code} 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:22:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2745) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2745: ---------------------------- Priority: Minor (was: Major) > Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2745 > URL: https://issues.jboss.org/browse/JBTM-2745 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The warning messages > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:22:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2745) Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2745: ---------------------------- Summary: Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI (was: Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI) > Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > --------------------------------------------------------------------------------------------------- > > Key: JBTM-2745 > URL: https://issues.jboss.org/browse/JBTM-2745 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The warning messages > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:23:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2745) Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng closed JBTM-2745. --------------------------- Resolution: Duplicate Issue > Warning messages show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > --------------------------------------------------------------------------------------------------- > > Key: JBTM-2745 > URL: https://issues.jboss.org/browse/JBTM-2745 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The warning messages > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Aug 30 12:37:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 30 Aug 2016 12:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2744) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1063 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2744 > URL: https://issues.jboss.org/browse/JBTM-2744 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The warning message are > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 31 06:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 31 Aug 2016 06:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2743: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: vc9x32 > Fix For: 5.next > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Aug 31 06:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 31 Aug 2016 06:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2744) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2744: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2744 > URL: https://issues.jboss.org/browse/JBTM-2744 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The warning message are > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)