From issues at jboss.org Sun Oct 2 16:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:30:00 -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 reopened JBTM-2728: --------------------------------- > 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.3.5.Final > > > 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 Sun Oct 2 16:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2755: --------------------------------- > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2755: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:30:00 -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: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.5.Final > > > 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 Sun Oct 2 16:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2755. ------------------------------- Resolution: Done > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:31:00 -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 closed JBTM-2728. ------------------------------- Resolution: Done > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.5.Final > > > 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 Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2747: --------------------------------- > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2747: -------------------------------- Fix Version/s: (was: 5.3.5.Final) > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34: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 reopened JBTM-2735: --------------------------------- > 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.3.5.Final > > > 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 Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34: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 closed JBTM-2735. ------------------------------- Resolution: Rejected > 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 > > 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 Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34: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: (was: 5.3.5.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 > Components: JTA, JTS > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > > 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 Sun Oct 2 16:34:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2747. ------------------------------- Resolution: Duplicate Issue > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Sun Oct 2 16:35:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 16:35: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:comment-tabpanel&focusedCommentId=13301368#comment-13301368 ] Tom Jenkinson commented on JBTM-2745: ------------------------------------- What issue was this a duplicate of? > 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.3.5.Final > > > 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 Sun Oct 2 17:11:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 2 Oct 2016 17:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301372#comment-13301372 ] Tom Jenkinson commented on JBTM-2763: ------------------------------------- Hi David, Which version of Oracle are you using? I think its because I am closing an underlying connection now but actually it is not meant to close for Oracle (and doesn't in the version I am using) but it matches on Driver name so that might be different in the version you are using. Many thanks, Tom > problem running with hibernate > ------------------------------ > > Key: JBTM-2763 > URL: https://issues.jboss.org/browse/JBTM-2763 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Environment: Spring 4.3.3.RELEASE > Hibernate 5.1.2.Final > Narayana 5.3.5 > Not in an application server - running standalone spring app > Reporter: davidkarlsen > > With the same libraries as above, except narayana 5.3.5 the following config worked just fine: > {noformat} > > > > > > > > > > > > > > > org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory > ${hibernate.cache.use_query_cache} > ${hibernate.cache.use_second_level_cache} > ${hibernate.generate_statistics} > ${hibernate.cache.use_structured_entries} > ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} > > ${hibernate.connection.release_mode:AFTER_STATEMENT} > ${hibernate.jdbc.use_get_generated_keys} > ${hibernate.jdbc.fetch_size} > ${hibernate.jdbc.batch_size} > ${hibernate.showSql} > ${hibernate.format_sql} > ${hibernate.use_sql_comments} > > > > {noformat} > If I upgrade Narayana to 5.3.5 I consistently get: > {noformat} > java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) > at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) > at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) > at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) > at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > at com.sun.proxy.$Proxy143.execute(Unknown Source) > at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) > at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) > at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) > at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) > at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) > at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) > at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) > at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) > 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.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) > 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. > {noformat} > If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: > {noformat} > WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception > 22:59:01 java.lang.NullPointerException: null > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) > 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) > 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) > 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) > 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) > 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) > 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) > 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) > 22:59:01 at > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 05:11:00 2016 From: issues at jboss.org (davidkarlsen (JIRA)) Date: Mon, 3 Oct 2016 05:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301445#comment-13301445 ] davidkarlsen commented on JBTM-2763: ------------------------------------ Oracle driver: 12.1.0.2.0 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- CON_ID ---------- Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 0 PL/SQL Release 12.1.0.2.0 - Production 0 CORE 12.1.0.2.0 Production 0 BANNER -------------------------------------------------------------------------------- CON_ID ---------- TNS for Linux: Version 12.1.0.2.0 - Production 0 NLSRTL Version 12.1.0.2.0 - Production 0 > problem running with hibernate > ------------------------------ > > Key: JBTM-2763 > URL: https://issues.jboss.org/browse/JBTM-2763 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Environment: Spring 4.3.3.RELEASE > Hibernate 5.1.2.Final > Narayana 5.3.5 > Not in an application server - running standalone spring app > Reporter: davidkarlsen > > With the same libraries as above, except narayana 5.3.5 the following config worked just fine: > {noformat} > > > > > > > > > > > > > > > org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory > ${hibernate.cache.use_query_cache} > ${hibernate.cache.use_second_level_cache} > ${hibernate.generate_statistics} > ${hibernate.cache.use_structured_entries} > ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} > > ${hibernate.connection.release_mode:AFTER_STATEMENT} > ${hibernate.jdbc.use_get_generated_keys} > ${hibernate.jdbc.fetch_size} > ${hibernate.jdbc.batch_size} > ${hibernate.showSql} > ${hibernate.format_sql} > ${hibernate.use_sql_comments} > > > > {noformat} > If I upgrade Narayana to 5.3.5 I consistently get: > {noformat} > java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) > at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) > at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) > at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) > at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > at com.sun.proxy.$Proxy143.execute(Unknown Source) > at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) > at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) > at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) > at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) > at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) > at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) > at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) > at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) > 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.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) > 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. > {noformat} > If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: > {noformat} > WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception > 22:59:01 java.lang.NullPointerException: null > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) > 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) > 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) > 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) > 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) > 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) > 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) > 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) > 22:59:01 at > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 08:24:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Oct 2016 08:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301593#comment-13301593 ] Tom Jenkinson commented on JBTM-2763: ------------------------------------- Hmm, actually I am not seeing this myself. I am using: https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate-standalone I have installed ojdbc7 in my .m2 and then have the following diffs on top: https://github.com/jbosstm/quickstart/compare/master...tomjenkinson:JBTM-2763 I can't replicate the issue you are seeing but likely my HHH config is different to yours. Feel free to modify my example to show the error you are seeing or maybe try to move your config closer to mine. I tried adding: To see it fail but I can't get it to fail there either. I think it would be useful to open a discussion so others can benefit: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d > problem running with hibernate > ------------------------------ > > Key: JBTM-2763 > URL: https://issues.jboss.org/browse/JBTM-2763 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Environment: Spring 4.3.3.RELEASE > Hibernate 5.1.2.Final > Narayana 5.3.5 > Not in an application server - running standalone spring app > Reporter: davidkarlsen > > With the same libraries as above, except narayana 5.3.5 the following config worked just fine: > {noformat} > > > > > > > > > > > > > > > org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory > ${hibernate.cache.use_query_cache} > ${hibernate.cache.use_second_level_cache} > ${hibernate.generate_statistics} > ${hibernate.cache.use_structured_entries} > ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} > > ${hibernate.connection.release_mode:AFTER_STATEMENT} > ${hibernate.jdbc.use_get_generated_keys} > ${hibernate.jdbc.fetch_size} > ${hibernate.jdbc.batch_size} > ${hibernate.showSql} > ${hibernate.format_sql} > ${hibernate.use_sql_comments} > > > > {noformat} > If I upgrade Narayana to 5.3.5 I consistently get: > {noformat} > java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) > at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) > at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) > at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) > at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > at com.sun.proxy.$Proxy143.execute(Unknown Source) > at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) > at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) > at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) > at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) > at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) > at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) > at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) > at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) > 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.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) > 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. > {noformat} > If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: > {noformat} > WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception > 22:59:01 java.lang.NullPointerException: null > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) > 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) > 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) > 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) > 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) > 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) > 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) > 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) > 22:59:01 at > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 08:24:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Oct 2016 08:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301593#comment-13301593 ] Tom Jenkinson edited comment on JBTM-2763 at 10/3/16 8:23 AM: -------------------------------------------------------------- Hmm, actually I am not seeing this myself. I am using: https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate-standalone I have installed ojdbc7 in my .m2 and then have the following diffs on top: https://github.com/jbosstm/quickstart/compare/master...tomjenkinson:JBTM-2763 I can't replicate the issue you are seeing but likely my HHH config is different to yours. Feel free to modify my example to show the error you are seeing or maybe try to move your config closer to mine. I tried adding: To see it fail but I can't get it to fail there either. I think it would be useful to open a discussion so others can benefit: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d was (Author: tomjenkinson): Hmm, actually I am not seeing this myself. I am using: https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate-standalone I have installed ojdbc7 in my .m2 and then have the following diffs on top: https://github.com/jbosstm/quickstart/compare/master...tomjenkinson:JBTM-2763 I can't replicate the issue you are seeing but likely my HHH config is different to yours. Feel free to modify my example to show the error you are seeing or maybe try to move your config closer to mine. I tried adding: To see it fail but I can't get it to fail there either. I think it would be useful to open a discussion so others can benefit: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d > problem running with hibernate > ------------------------------ > > Key: JBTM-2763 > URL: https://issues.jboss.org/browse/JBTM-2763 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Environment: Spring 4.3.3.RELEASE > Hibernate 5.1.2.Final > Narayana 5.3.5 > Not in an application server - running standalone spring app > Reporter: davidkarlsen > > With the same libraries as above, except narayana 5.3.5 the following config worked just fine: > {noformat} > > > > > > > > > > > > > > > org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory > ${hibernate.cache.use_query_cache} > ${hibernate.cache.use_second_level_cache} > ${hibernate.generate_statistics} > ${hibernate.cache.use_structured_entries} > ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} > > ${hibernate.connection.release_mode:AFTER_STATEMENT} > ${hibernate.jdbc.use_get_generated_keys} > ${hibernate.jdbc.fetch_size} > ${hibernate.jdbc.batch_size} > ${hibernate.showSql} > ${hibernate.format_sql} > ${hibernate.use_sql_comments} > > > > {noformat} > If I upgrade Narayana to 5.3.5 I consistently get: > {noformat} > java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) > at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) > at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) > at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) > at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > at com.sun.proxy.$Proxy143.execute(Unknown Source) > at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) > at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) > at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) > at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) > at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) > at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) > at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) > at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) > 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.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) > 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. > {noformat} > If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: > {noformat} > WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception > 22:59:01 java.lang.NullPointerException: null > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) > 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) > 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) > 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) > 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) > 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) > 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) > 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) > 22:59:01 at > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 08:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Oct 2016 08:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13301593#comment-13301593 ] Tom Jenkinson edited comment on JBTM-2763 at 10/3/16 8:24 AM: -------------------------------------------------------------- Hmm, actually I am not seeing this myself. I am using: https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate-standalone I have installed ojdbc7 in my .m2 and then have the following diffs on top: https://github.com/jbosstm/quickstart/compare/master...tomjenkinson:JBTM-2763 I can't replicate the issue you are seeing but likely my HHH config is different to yours. Feel free to modify my example to show the error you are seeing or maybe try to move your config closer to mine. I tried adding: {code} {code} To see it fail but I can't get it to fail there either. I think it would be useful to open a discussion so others can benefit: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d was (Author: tomjenkinson): Hmm, actually I am not seeing this myself. I am using: https://github.com/jbosstm/quickstart/tree/master/jta-and-hibernate-standalone I have installed ojdbc7 in my .m2 and then have the following diffs on top: https://github.com/jbosstm/quickstart/compare/master...tomjenkinson:JBTM-2763 I can't replicate the issue you are seeing but likely my HHH config is different to yours. Feel free to modify my example to show the error you are seeing or maybe try to move your config closer to mine. I tried adding: To see it fail but I can't get it to fail there either. I think it would be useful to open a discussion so others can benefit: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d > problem running with hibernate > ------------------------------ > > Key: JBTM-2763 > URL: https://issues.jboss.org/browse/JBTM-2763 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.5.Final > Environment: Spring 4.3.3.RELEASE > Hibernate 5.1.2.Final > Narayana 5.3.5 > Not in an application server - running standalone spring app > Reporter: davidkarlsen > > With the same libraries as above, except narayana 5.3.5 the following config worked just fine: > {noformat} > > > > > > > > > > > > > > > org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory > ${hibernate.cache.use_query_cache} > ${hibernate.cache.use_second_level_cache} > ${hibernate.generate_statistics} > ${hibernate.cache.use_structured_entries} > ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} > > ${hibernate.connection.release_mode:AFTER_STATEMENT} > ${hibernate.jdbc.use_get_generated_keys} > ${hibernate.jdbc.fetch_size} > ${hibernate.jdbc.batch_size} > ${hibernate.showSql} > ${hibernate.format_sql} > ${hibernate.use_sql_comments} > > > > {noformat} > If I upgrade Narayana to 5.3.5 I consistently get: > {noformat} > java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) > at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) > at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) > at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) > at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) > at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) > at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) > at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) > at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) > at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) > at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) > at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > at com.sun.proxy.$Proxy143.execute(Unknown Source) > at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) > at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) > at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) > at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) > at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) > at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) > at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) > at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) > 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.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) > at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) > 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. > {noformat} > If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: > {noformat} > WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception > 22:59:01 java.lang.NullPointerException: null > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) > 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) > 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) > 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) > 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) > 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) > 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) > 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) > 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) > 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) > 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) > 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) > 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) > 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) > 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) > 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) > 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) > 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) > 22:59:01 at > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 10:11:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2738) Upgrade jboss-transaction-spi dependency to 7.5.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2738: ----------------------------------- Summary: Upgrade jboss-transaction-spi dependency to 7.5.0.Final (was: Upgrade jboss-transaction-spi dependency to 7.3.3.Final) > Upgrade jboss-transaction-spi dependency to 7.5.0.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 Oct 3 10:16:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2738) Upgrade jboss-transaction-spi dependency to 7.5.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2738. ---------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) Resolution: Done Fixed by commit 7907225 > Upgrade jboss-transaction-spi dependency to 7.5.0.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.3.5.Final > > > 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 Oct 3 10:18:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:18: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 closed JBTM-2449. ---------------------------------- Resolution: Done PR merged and released > 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 Oct 3 10:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Oct 2016 10:22: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:comment-tabpanel&focusedCommentId=13301691#comment-13301691 ] Tom Jenkinson commented on JBTM-2449: ------------------------------------- Should it have a different fix version? > 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 Oct 3 10:40:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:40: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:comment-tabpanel&focusedCommentId=13301709#comment-13301709 ] Michael Musgrove commented on JBTM-2449: ---------------------------------------- The problem is that we do not have a separate project for the SPI and we use a narayana JIRA for tracking SPI changes. But sometimes (although rarely) we release the SPI for projects other than narayana (this JIRA is such an example). The fix went into jboss-transaction:7.3.3.Final and the first narayana release that consumed that version was 5.3.5.Final so I an option would be to use that as the fix version field. > 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 Oct 3 10:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Oct 2016 10:51: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:comment-tabpanel&focusedCommentId=13301716#comment-13301716 ] Tom Jenkinson commented on JBTM-2449: ------------------------------------- Sure, I think that is a good idea to use the fixVersion that includes the module update. > 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 Oct 3 10:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:58: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: ------------------------------------ Changing fix version field > 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 Oct 3 10:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:58: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 updated JBTM-2449: ----------------------------------- Fix Version/s: 5.3.5.Final (was: 5.2.0) > 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.3.5.Final > > > 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 Oct 3 10:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 3 Oct 2016 10:58: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 closed JBTM-2449. ---------------------------------- Resolution: Done > 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.3.5.Final > > > 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 Oct 3 11:23:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:23: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 ] Issue was automatically transitioned when Gytis Trikleris created pull request #1076 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > 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 Oct 3 11:26:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2764) Simple Narayana and Tomcat quickstart to demonstrate new module In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2764: ------------------------------------- Summary: Simple Narayana and Tomcat quickstart to demonstrate new module Key: JBTM-2764 URL: https://issues.jboss.org/browse/JBTM-2764 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 11:28:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2765) Document Narayana Tomcat module In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2765: ------------------------------------- Summary: Document Narayana Tomcat module Key: JBTM-2765 URL: https://issues.jboss.org/browse/JBTM-2765 Project: JBoss Transaction Manager Issue Type: Task Components: Documentation Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 11:29:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:29: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 was: 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) > 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 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 11:29:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:29: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 was: 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 > 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 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 3 11:30:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 3 Oct 2016 11:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2766) Implement pooling for transactional driver In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2766: ------------------------------------- Summary: Implement pooling for transactional driver Key: JBTM-2766 URL: https://issues.jboss.org/browse/JBTM-2766 Project: JBoss Transaction Manager Issue Type: Task Components: JTA Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 07:03:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 4 Oct 2016 07:03: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:comment-tabpanel&focusedCommentId=13302114#comment-13302114 ] Amos Feng commented on JBTM-2745: --------------------------------- I think it is duplicated to the JBTM-2744 and I created two issues with clicking the button twice. > 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.3.5.Final > > > 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 Oct 4 07:14:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 4 Oct 2016 07:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2761) Add the nexus repository to the OSGi quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2761: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add the nexus repository to the OSGi quickstart > ----------------------------------------------- > > Key: JBTM-2761 > URL: https://issues.jboss.org/browse/JBTM-2761 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Can't be found by the CI system until it flushes to maven central -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 4 07:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 4 Oct 2016 07:15:02 -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 ] Tom Jenkinson reopened JBTM-2745: --------------------------------- > 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.3.5.Final > > > 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 Oct 4 07:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 4 Oct 2016 07:15:02 -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 ] Tom Jenkinson 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 > > 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 Oct 4 07:15:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 4 Oct 2016 07:15:02 -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 ] Tom Jenkinson updated JBTM-2745: -------------------------------- Fix Version/s: (was: 5.3.5.Final) > 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 > > 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 Oct 4 09:09:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Oct 2016 09:09: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=13302277#comment-13302277 ] RH Bugzilla Integration commented on JBTM-2614: ----------------------------------------------- Ji?? B?lek changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from ON_QA to VERIFIED > 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 Tue Oct 4 09:09:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Oct 2016 09:09:00 -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:comment-tabpanel&focusedCommentId=13302276#comment-13302276 ] RH Bugzilla Integration commented on JBTM-2708: ----------------------------------------------- Ji?? B?lek changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from ON_QA to VERIFIED > 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: 4.17.35, 5.3.4.Final > > > {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 Tue Oct 4 09:09:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Oct 2016 09:09: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:comment-tabpanel&focusedCommentId=13302275#comment-13302275 ] RH Bugzilla Integration commented on JBTM-2709: ----------------------------------------------- Ji?? B?lek changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from ON_QA to VERIFIED > 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: 4.17.35, 5.3.4.Final > > > 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 Wed Oct 5 10:41:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 5 Oct 2016 10:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JTS: EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka moved JBEAP-6308 to JBTM-2767: ---------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2767 (was: JBEAP-6308) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JTS (was: Transactions) Affects Version/s: 5.3.5.Final (was: 7.1.0.DR6) > JTS: EIS can't recover transaction when heuristic outcome happens > ----------------------------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log > > > I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario > {quote} > * test client sends prepare command > * test client sends commit command > * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start > * test client gets error code {{XAException#XA_HEURMIX}} > * now the transaction participant is in heuristic state > * tried to commit the created txn -> fails as in heuristic and can't be operated > * using {{:recover}} command for the transaction participant > * tried to commit the txn -> expecting the commit succeed and txn is committed > {quote} > There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. > Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > [2] > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => undefined > } > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => true, > "type" => "default", > "transactions" => { > "0:ffff7f000001:3716dcba:57f50b7d:14" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", > "jmx-name" => undefined, > "type" => "Recovery/FactoryContact", > "participants" => undefined > }, > "0:ffff7f000001:3716dcba:57f50b7d:28" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => undefined > }, > "0:ffff52e38d0c:c91:4140398c:0" => { > "age-in-seconds" => undefined, > "id" => "0:ffff52e38d0c:c91:4140398c:0", > "jmx-name" => undefined, > "type" => "RecoveryCoordinator", > "participants" => undefined > } > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 5 10:43:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 5 Oct 2016 10:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JTS: EIS can't recover transaction when heuristic outcome happens In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13303016#comment-13303016 ] Ondra Chaloupka commented on JBTM-2767: --------------------------------------- This is the same testcase as in {{JBTM-2734}} and it passes for JTA. I'm not 100% sure if there is not needed a special handling for JTS. Especially the trouble of getting participants of transaction seems to me strange. > JTS: EIS can't recover transaction when heuristic outcome happens > ----------------------------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > Attachments: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log > > > I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario > {quote} > * test client sends prepare command > * test client sends commit command > * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start > * test client gets error code {{XAException#XA_HEURMIX}} > * now the transaction participant is in heuristic state > * tried to commit the created txn -> fails as in heuristic and can't be operated > * using {{:recover}} command for the transaction participant > * tried to commit the txn -> expecting the commit succeed and txn is committed > {quote} > There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. > Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > [2] > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => undefined > } > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => true, > "type" => "default", > "transactions" => { > "0:ffff7f000001:3716dcba:57f50b7d:14" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", > "jmx-name" => undefined, > "type" => "Recovery/FactoryContact", > "participants" => undefined > }, > "0:ffff7f000001:3716dcba:57f50b7d:28" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => undefined > }, > "0:ffff52e38d0c:c91:4140398c:0" => { > "age-in-seconds" => undefined, > "id" => "0:ffff52e38d0c:c91:4140398c:0", > "jmx-name" => undefined, > "type" => "RecoveryCoordinator", > "participants" => undefined > } > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 03:30:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Oct 2016 03: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:comment-tabpanel&focusedCommentId=13303277#comment-13303277 ] RH Bugzilla Integration commented on JBTM-2720: ----------------------------------------------- Ji?? B?lek changed the Status of [bug 1367187|https://bugzilla.redhat.com/show_bug.cgi?id=1367187] from ON_QA to VERIFIED > 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 Oct 6 11:26:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 6 Oct 2016 11:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2768) Improve ease of use of JTS on Tomcat In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2768: ------------------------------------- Summary: Improve ease of use of JTS on Tomcat Key: JBTM-2768 URL: https://issues.jboss.org/browse/JBTM-2768 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTS Reporter: Gytis Trikleris Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 12:48:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 6 Oct 2016 12:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2769: ------------------------------------- Summary: Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic Key: JBTM-2769 URL: https://issues.jboss.org/browse/JBTM-2769 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Blocker I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). 1) * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. 2) * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted * The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. {code} 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 12:49:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 6 Oct 2016 12:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2769: ---------------------------------- Affects Version/s: 5.3.5.Final > Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic > ----------------------------------------------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Priority: Blocker > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > 1) > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > 2) > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > * > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 12:49:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 6 Oct 2016 12:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2769: ------------------------------------- Assignee: Michael Musgrove > Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic > ----------------------------------------------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > 1) > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > 2) > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > * > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 12:56:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 6 Oct 2016 12:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2769: ---------------------------------- Attachment: JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log > Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic > ----------------------------------------------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log > > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > 1) > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > 2) > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > * > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 6 12:56:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 6 Oct 2016 12:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2769: ---------------------------------- Description: I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). ad 1. * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. ad 2. * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. {code} 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) {code} was: I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). 1) * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. 2) * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted * The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. {code} 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) {code} > Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic > ----------------------------------------------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log > > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > ad 1. > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > ad 2. > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 10 05:30:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 10 Oct 2016 05:30: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: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:12:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 05:12:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2770: ------------------------------------- Summary: Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource Key: JBTM-2770 URL: https://issues.jboss.org/browse/JBTM-2770 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Blocker I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) The scenario which I run is following {quote} * enlist test xa resource * enlist cmr db resource * prepare cmr db resource * prepare test xa resource * commit cmr db resource * crash app server * start server and halt connection to DB * do recovery of test xa resource which is expected being committed {quote} What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. {code} 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:12:01 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 05:12:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2770: ------------------------------------- Assignee: Tom Jenkinson > Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource > ------------------------------------------------------------------------ > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:13:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 05:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2770: ---------------------------------- Attachment: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log > Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource > ------------------------------------------------------------------------ > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log > > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 05:13:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 05:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2770: ---------------------------------- Affects Version/s: 5.3.5.Final > Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource > ------------------------------------------------------------------------ > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log > > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2771: ---------------------------------- Affects Version/s: 5.3.5.Final > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2771: ------------------------------------- Assignee: Ondra Chaloupka > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2771: ---------------------------------- Attachment: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2771: ------------------------------------- Assignee: Tom Jenkinson (was: Ondra Chaloupka) > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2771: ------------------------------------- Summary: JTS works incorrectly for JMS connection being interrupted at commit phase Key: JBTM-2771 URL: https://issues.jboss.org/browse/JBTM-2771 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Blocker I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. The following scenario fails when JTS is used {quote} * prepare jms XA * stop connection to jms broker * prepare test XA * call commit on jms XA as connection is down we can experience {{XAException.XA_RETRY}} * commit test XA (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) * recovery: commit jms XA {quote} in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. {code} 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 11 13:14:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 11 Oct 2016 13:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2771: ---------------------------------- Component/s: JTS > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 06:31:03 2016 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 12 Oct 2016 06:31:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2772) Introduce an authorization SPI In-Reply-To: References: Message-ID: David Lloyd created JBTM-2772: --------------------------------- Summary: Introduce an authorization SPI Key: JBTM-2772 URL: https://issues.jboss.org/browse/JBTM-2772 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Application Server Integration Reporter: David Lloyd Assignee: Amos Feng We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. The operations that should provide authorization checks include, but are not limited to: * begin * rollback * prepare * forget * commit (one or two phase) * recover Thanks! -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 12 22:28:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 12 Oct 2016 22:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2772) Introduce an authorization SPI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2772: ---------------------------- Component/s: SPI > Introduce an authorization SPI > ------------------------------ > > Key: JBTM-2772 > URL: https://issues.jboss.org/browse/JBTM-2772 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Application Server Integration, SPI > Reporter: David Lloyd > Assignee: Amos Feng > > We need an SPI that can be invoked to authorize state changes in a transaction. The method(s) should make it clear in some way which operation is being authorized, and it must run from the same thread as the thread which instigates the state change. > It must be possible to register an implementation of the SPI when the container starts up or acquires the transaction manager. > The operations that should provide authorization checks include, but are not limited to: > * begin > * rollback > * prepare > * forget > * commit (one or two phase) > * recover > Thanks! -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 17 09:58:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 17 Oct 2016 09:58:00 -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 ] Issue was automatically transitioned when Gytis Trikleris created pull request #1077 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > 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 Tue Oct 18 04:53:00 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Tue, 18 Oct 2016 04:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2773) NPE when trying delete heuristic transaction (with CMR resource) from JDBC tx log-store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Simko moved JBEAP-6468 to JBTM-2773: ------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2773 (was: JBEAP-6468) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Transaction Core (was: Transactions) Affects Version/s: 5.3.5.Final (was: 7.1.0.DR6) Affects Testing: (was: Regression) > NPE when trying delete heuristic transaction (with CMR resource) from JDBC tx log-store > --------------------------------------------------------------------------------------- > > Key: JBTM-2773 > URL: https://issues.jboss.org/browse/JBTM-2773 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.5.Final > Reporter: Daniel Simko > Assignee: Tom Jenkinson > Priority: Critical > > Part of the test is cleaning tx log-store: > {code} > 14:36:46,747 ERROR [org.jboss.as.test.jbossts.base.setup.operations.TMOperations] (main) Management operation { > "operation" => "delete", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff7f000001:-475b5c9c:5804af44:31") > ] > } failed: { > "outcome" => "failed", > "failure-description" => "java.lang.NullPointerException", > "rolled-back" => true > } > {code} > but fails with NPE. Server log: > {code} > 2016-10-17 14:36:42,798 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:42,798 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:43,140 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:43,140 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::BasicAction(0:ffff7f000001:-475b5c9c:5804af44:31) > 2016-10-17 14:36:43,141 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::activate() for action-id 0:ffff7f000001:-475b5c9c:5804af44:31 > 2016-10-17 14:36:43,308 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:43,474 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::restore_state () > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager.unpackHeader for object-id 0:ffff7f000001:-475b5c9c:5804af44:31 birth-date 1476707800081 > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Unpacked a 463 record > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked heuristic list size of 1 > 2016-10-17 14:36:43,475 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) Transaction 0:ffff7f000001:-475b5c9c:5804af44:31 has 1 heuristic participant(s)! > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked a 50 record > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:0:0:0:0 ) > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) AbstractRecord::AbstractRecord () - crash recovery constructor > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecord.CommitMarkableResourceRecord (), record id=-8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) unpack: java:jboss/xa-datasources/CrashRecoveryDS > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) unpack: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-475b5c9c:5804af44:31, node_name=1, branch_uid=0:ffff7f000001:-475b5c9c:5804af44:37, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > > 2016-10-17 14:36:43,476 TRACE [com.arjuna.ats.jta] (management-handler-thread - 4) TransactionSynchronizationRegistryImple.getTransactionKey > 2016-10-17 14:36:43,476 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Attempting to delete number of entries: 2 > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecordRecoveryModule::connecting to: java:jboss/xa-datasources/CrashRecoveryDS > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.jta] (management-handler-thread - 4) TransactionSynchronizationRegistryImple.getTransactionKey > 2016-10-17 14:36:44,334 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:44,335 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:44,669 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions > 2016-10-17 14:36:44,669 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:44,669 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:45,002 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:45,002 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:45,838 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:46,004 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:46,004 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::BasicAction(0:ffff7f000001:-475b5c9c:5804af44:31) > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager.unpackHeader for object-id 0:ffff7f000001:-475b5c9c:5804af44:31 birth-date 1476707800081 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) wasCommitted< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-475b5c9c:5804af44:31, node_name=1, branch_uid=0:ffff7f000001:-475b5c9c:5804af44:37, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > null > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/CommitMarkableResourceRecord for -8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 > 2016-10-17 14:36:46,005 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) Transaction 0:ffff7f000001:-475b5c9c:5804af44:31 restored heuristic participant com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord at 2493dae0 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked a 463 record > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored action status of ActionStatus.COMMITTED 7 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored action type Top-level 0 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored heuristic decision of TwoPhaseOutcome.HEURISTIC_ROLLBACK 3 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:46,174 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:46,344 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::activate( null) for object-id 0:0:0:0:0 > 2016-10-17 14:36:46,345 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::setupStore ( null ) > 2016-10-17 14:36:46,682 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) ARJUNA012035: Activate of object with id = 0:0:0:0:0 and type /StateManager/AbstractRecord/CommitMarkableResourceRecord unexpectedly failed > 2016-10-17 14:36:46,682 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Registering: jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31 > 2016-10-17 14:36:46,682 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) registering bean jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31 > 2016-10-17 14:36:46,683 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) registering bean jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31,puid=-8000000000000000_-8000000000000000_-80000000_-80000000_-80000000 > {code} > Test passed for EAP 7.1.0.DR5 but failed for EAP 7.1.0.DR6. For another types of log-store (standard file based, activemq artemis journal) test passed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 18 10:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 18 Oct 2016 10:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2774: ----------------------------------- Summary: Leak when imported subordinate transactions are rolled back by reaper before remote reaper Key: JBTM-2774 URL: https://issues.jboss.org/browse/JBTM-2774 Project: JBoss Transaction Manager Issue Type: Bug Components: Application Server Integration Reporter: Tom Jenkinson Assignee: Tom Jenkinson When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Oct 18 10:24:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 18 Oct 2016 10:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1078 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 01:56:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Oct 2016 01:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309048#comment-13309048 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Radovan Netuka changed the Status of [bug 1383572|https://bugzilla.redhat.com/show_bug.cgi?id=1383572] from ASSIGNED to POST > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 04:37:02 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Oct 2016 04:37:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309136#comment-13309136 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Peter Palaga changed the Status of [bug 1383572|https://bugzilla.redhat.com/show_bug.cgi?id=1383572] from MODIFIED to POST > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Oct 19 08:57:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Oct 2016 08:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13309284#comment-13309284 ] RH Bugzilla Integration commented on JBTM-2749: ----------------------------------------------- Peter Palaga changed the Status of [bug 1383572|https://bugzilla.redhat.com/show_bug.cgi?id=1383572] from POST to MODIFIED > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2739) Add a CI job for testing jboss-transaction-spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2739: -------------------------------- Fix Version/s: 5.2.19.Final > 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.2.19.Final, 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 Thu Oct 20 05:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2749: --------------------------------- > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2749: -------------------------------- Fix Version/s: 5.2.19.Final 4.17.37 > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 4.17.37, 5.2.19.Final, 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2749. ------------------------------- Resolution: Done > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final, 5.2.19.Final, 4.17.37 > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:42:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:42:00 -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 updated JBTM-2703: -------------------------------- Fix Version/s: 5.2.18.Final > 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.2.18.Final, 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 Thu Oct 20 05:42:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:42:00 -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. ------------------------------- Resolution: Done > 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, 5.2.18.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 Thu Oct 20 05:42:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:42:00 -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 reopened 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 Thu Oct 20 05:45:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2672: --------------------------------- > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Fix For: 5.2.17.Final > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:45:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2672: -------------------------------- Fix Version/s: (was: 5.2.17.Final) > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2672) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2672. ------------------------------- Resolution: Duplicate Issue > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2672 > URL: https://issues.jboss.org/browse/JBTM-2672 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.2.14.Final > Reporter: Bartosz Baranowski > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 05:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:49:00 -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 reopened 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.2.18.Final, 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 Thu Oct 20 05:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:49:00 -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 updated JBTM-2703: -------------------------------- Fix Version/s: 4.17.35 > 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: 4.17.35, 5.2.18.Final, 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 Thu Oct 20 05:49:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 05:49:01 -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. ------------------------------- Resolution: Done > 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, 5.2.18.Final, 4.17.35 > > > {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 Thu Oct 20 11:36:01 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Oct 2016 11:36:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2774: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1387316 Bugzilla Update: Perform > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 11:38:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 11:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2774: -------------------------------- Priority: Critical (was: Major) > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.38, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 11:38:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 11:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2774: -------------------------------- Fix Version/s: 4.17.38 5.2.20.Final 5.next > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.38, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 11:38:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 11:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2774: -------------------------------- Fix Version/s: (was: 5.2.20.Final) > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.38, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 11:55:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Oct 2016 11:55:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2774: -------------------------------- Fix Version/s: 5.2.20.Final > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.38, 5.2.20.Final, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Oct 20 12:43:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Oct 2016 12:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310025#comment-13310025 ] RH Bugzilla Integration commented on JBTM-2774: ----------------------------------------------- Fedor Gavrilov changed the Status of [bug 1387316|https://bugzilla.redhat.com/show_bug.cgi?id=1387316] from NEW to ASSIGNED > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.38, 5.2.20.Final, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 03:32:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 03:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2775) Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2775: ------------------------------- Summary: Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 Key: JBTM-2775 URL: https://issues.jboss.org/browse/JBTM-2775 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next This is a preview release allowing Byteman to be used with a JDK9 that includes the Java Platform Module System. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 03:36:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 03:36: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=13310206#comment-13310206 ] Amos Feng commented on JBTM-2685: --------------------------------- It needs to upgrade the byteman to 4.0.0-BETA0 and the ArjunaJTA/jta tests with the byteman rules should work. I had test them with the jdk9-ea+140 although the byteman throws the Exception {code} AccessManager:init unexpected error initialising JigsawAccessManager java.lang.reflect.InvocationTargetException at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:535) at org.jboss.byteman.agent.AccessManager.init(AccessManager.java:80) at org.jboss.byteman.agent.Transformer.(Transformer.java:98) at org.jboss.byteman.agent.Retransformer.(Retransformer.java:60) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base at 9-ea/NativeConstructorAccessorImpl.java:62) at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base at 9-ea/DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(java.base at 9-ea/Constructor.java:455) at org.jboss.byteman.agent.Main.premain(Main.java:269) at org.jboss.byteman.agent.Main.agentmain(Main.java:307) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9-ea/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 9-ea/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9-ea/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9-ea/Method.java:535) at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(java.instrument at 9-ea/InstrumentationImpl.java:396) at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(java.instrument at 9-ea/InstrumentationImpl.java:418) Caused by: java.lang.NoSuchMethodError: java.lang.module.ModuleDescriptor.module(Ljava/lang/String;)Ljava/lang/module/ModuleDescriptor$Builder; at org.jboss.byteman.layer.LayerModuleFinder.(LayerModuleFinder.java:82) at org.jboss.byteman.layer.LayerFactory.installModule(LayerFactory.java:63) at org.jboss.byteman.agent.JigsawAccessManager.init(JigsawAccessManager.java:63) ... 19 more {code} > 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 Fri Oct 21 03:39:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 03:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2775) Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #1081 in GitHub ---------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 > --------------------------------------------------- > > Key: JBTM-2775 > URL: https://issues.jboss.org/browse/JBTM-2775 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > This is a preview release allowing Byteman to be used with a JDK9 that includes the Java Platform Module System. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 03:45:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 03:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2776) Investigate the arquillian issue with the JDK 9 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2776: ------------------------------- Summary: Investigate the arquillian issue with the JDK 9 Key: JBTM-2776 URL: https://issues.jboss.org/browse/JBTM-2776 Project: JBoss Transaction Manager Issue Type: Sub-task Reporter: Amos Feng Assignee: Amos Feng the arquillian can not create the container -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 03:49:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 03:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2776) Investigate the arquillian tests failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2776: ---------------------------- Summary: Investigate the arquillian tests failure with the JDK 9 (was: Investigate the arquillian issue with the JDK 9) > Investigate the arquillian tests failure with the JDK 9 > ------------------------------------------------------- > > Key: JBTM-2776 > URL: https://issues.jboss.org/browse/JBTM-2776 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > the arquillian can not create the container -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 04:21:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 04:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9 In-Reply-To: References: Message-ID: Amos Feng created JBTM-2777: ------------------------------- Summary: Investigate the osgi test failure with the JDK 9 Key: JBTM-2777 URL: https://issues.jboss.org/browse/JBTM-2777 Project: JBoss Transaction Manager Issue Type: Sub-task Reporter: Amos Feng Assignee: Amos Feng The arquillian can not start the karaf. {code} -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs in modular form will be supported via the concept of upgradeable modules. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 10:06:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 21 Oct 2016 10:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2774) Leak when imported subordinate transactions are rolled back by reaper before remote reaper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2774: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Leak when imported subordinate transactions are rolled back by reaper before remote reaper > ------------------------------------------------------------------------------------------ > > Key: JBTM-2774 > URL: https://issues.jboss.org/browse/JBTM-2774 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.38, 5.2.20.Final, 5.next > > > When using the EJB remoting transport that layers over the top of JCA it is possible for a race condition between the two reapers. > Normally you have server 1 and server 2. Each of these insert the TwoPhaseCoordinator in their TransactionReaper. If the TransactionReaper in server 2 fires first then it will rollback the TPC. > When server 1 Reaper EJB remoting transport fires it will try to rollback at server 2 also and it is this that should be safe to remove the transactionImple reference. > At the time of reporting the reference is not removed though and so the reference to the TransactionImple is not removed. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:46:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2777: ---------------------------- Labels: jdk9 (was: ) > Investigate the osgi test failure with the JDK 9 > ------------------------------------------------ > > Key: JBTM-2777 > URL: https://issues.jboss.org/browse/JBTM-2777 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > Fix For: 5.next > > > The arquillian can not start the karaf. > {code} > -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:46:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2776) Investigate the arquillian tests failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2776: ---------------------------- Labels: jdk9 (was: ) > Investigate the arquillian tests failure with the JDK 9 > ------------------------------------------------------- > > Key: JBTM-2776 > URL: https://issues.jboss.org/browse/JBTM-2776 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > Fix For: 5.next > > > the arquillian can not create the container -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:49:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2777: ---------------------------- Priority: Minor (was: Major) > Investigate the osgi test failure with the JDK 9 > ------------------------------------------------ > > Key: JBTM-2777 > URL: https://issues.jboss.org/browse/JBTM-2777 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Labels: jdk9 > Fix For: 5.next > > > The arquillian can not start the karaf. > {code} > -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:50:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2777) Investigate the osgi test failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310486#comment-13310486 ] Amos Feng commented on JBTM-2777: --------------------------------- It looks like that we need to wait until the [KARAF-3518|https://issues.apache.org/jira/browse/KARAF-3518] resolved > Investigate the osgi test failure with the JDK 9 > ------------------------------------------------ > > Key: JBTM-2777 > URL: https://issues.jboss.org/browse/JBTM-2777 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Labels: jdk9 > Fix For: 5.next > > > The arquillian can not start the karaf. > {code} > -Djava.endorsed.dirs=/home/zhfeng/work/zhfeng/narayana-jdk9/osgi/jta/target/apache-karaf-minimal-4.0.5/lib/endorsed is not supported. Endorsed standards and standalone APIs > in modular form will be supported via the concept of upgradeable modules. > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:53:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2778) Upgrade arquillian-container-karaf to 2.2.0.Final In-Reply-To: References: Message-ID: Amos Feng created JBTM-2778: ------------------------------- Summary: Upgrade arquillian-container-karaf to 2.2.0.Final Key: JBTM-2778 URL: https://issues.jboss.org/browse/JBTM-2778 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration, Build System Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next The arquillian-container-karaf had release the 2.2.0.Final and it does not need to build the SNAPSHOT in the hudson/script/narayana.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 21 Oct 2016 11:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2778) Upgrade arquillian-container-karaf to 2.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310491#comment-13310491 ] Tom Jenkinson commented on JBTM-2778: ------------------------------------- Hi Amos, I think I added a commit for this but against an old issue. I will get the link... Tom > Upgrade arquillian-container-karaf to 2.2.0.Final > -------------------------------------------------- > > Key: JBTM-2778 > URL: https://issues.jboss.org/browse/JBTM-2778 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The arquillian-container-karaf had release the 2.2.0.Final and it does not need to build the SNAPSHOT in the hudson/script/narayana.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 21 Oct 2016 11:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2778) Upgrade arquillian-container-karaf to 2.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2778. --------------------------------- Assignee: Tom Jenkinson (was: Amos Feng) Resolution: Done > Upgrade arquillian-container-karaf to 2.2.0.Final > -------------------------------------------------- > > Key: JBTM-2778 > URL: https://issues.jboss.org/browse/JBTM-2778 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Tom Jenkinson > Fix For: 5.next > > > The arquillian-container-karaf had release the 2.2.0.Final and it does not need to build the SNAPSHOT in the hudson/script/narayana.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 21 Oct 2016 11:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2778) Upgrade arquillian-container-karaf to 2.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310492#comment-13310492 ] Tom Jenkinson commented on JBTM-2778: ------------------------------------- https://github.com/jbosstm/narayana/commit/7e6e7f790df9374f917ee19eb2f379189159fa2a > Upgrade arquillian-container-karaf to 2.2.0.Final > -------------------------------------------------- > > Key: JBTM-2778 > URL: https://issues.jboss.org/browse/JBTM-2778 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The arquillian-container-karaf had release the 2.2.0.Final and it does not need to build the SNAPSHOT in the hudson/script/narayana.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Oct 21 11:59:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 21 Oct 2016 11:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2778) Upgrade arquillian-container-karaf to 2.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13310493#comment-13310493 ] Amos Feng commented on JBTM-2778: --------------------------------- Thanks Tom > Upgrade arquillian-container-karaf to 2.2.0.Final > -------------------------------------------------- > > Key: JBTM-2778 > URL: https://issues.jboss.org/browse/JBTM-2778 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, Build System > Reporter: Amos Feng > Assignee: Tom Jenkinson > Fix For: 5.next > > > The arquillian-container-karaf had release the 2.2.0.Final and it does not need to build the SNAPSHOT in the hudson/script/narayana.sh -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 24 09:41:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 24 Oct 2016 09:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2775) Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2775: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade byteman to 4.0.0-BETA0 to support the JDK 9 > --------------------------------------------------- > > Key: JBTM-2775 > URL: https://issues.jboss.org/browse/JBTM-2775 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > This is a preview release allowing Byteman to be used with a JDK9 that includes the Java Platform Module System. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Oct 24 10:39:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 24 Oct 2016 10:39: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=13310914#comment-13310914 ] Amos Feng commented on JBTM-2685: --------------------------------- It should download the Jigsaw ea release from https://jdk9.java.net/jigsaw to resolve this exception. > 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 Tue Oct 25 11:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 25 Oct 2016 11:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2779) Add licence file to missing quickstarts In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2779: ----------------------------------- Summary: Add licence file to missing quickstarts Key: JBTM-2779 URL: https://issues.jboss.org/browse/JBTM-2779 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator Reporter: Tom Jenkinson Assignee: Amos Feng Fix For: 5.next There are a lot of quickstarts that do not have the expected licence declarations at the top of their files. You can find these: find . -type f | grep -v git | grep -v jar | grep -v tools | xargs grep -H -c 'Lesser\|LICENSE-2' | grep 0$ | cut -d':' -f1 | wc The correct licence should be added to them, you may find it easy to cat a licence file (in the correct .java, .xml, .sh, .bat format) to them. The licence is LGPL. Those that were originally ASL etc should remain that way. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2780: ------------------------------------- Summary: JTS recovery does not process commit when connection is halt during 2PC Key: JBTM-2780 URL: https://issues.jboss.org/browse/JBTM-2780 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Priority: Critical Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. # first app server receives a message via MDB #onMessage from artemis broker (second eap server) # during onMessage processing a enw message is send to different remote queue on artemis broker # testing XA resource is enlisted to txn # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned # the test XAResource is committed # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2780: ---------------------------------- Attachment: .jts_haltConnectionAfterDbCommits_server.log.syntax haltConnectionAfterDbCommits_standalone-full.xml > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2780: ---------------------------------- Affects Version/s: 5.3.5.Final > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2780: ---------------------------------- Component/s: JTS Recovery > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Recovery > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:26:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2780: ------------------------------------- Assignee: Tom Jenkinson > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Tue Oct 25 15:28:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Oct 2016 15:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2780: ---------------------------------- Steps to Reproduce: The behavior could be observed when jts test is run in crashrec testsuite. Test does not fail every time as it could happen that txn is rolled back and MDB then process the message for second time and thus the final checks can observe message being committed. But the server log always show what was the process. {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... (downloadable at http://download.eng.brq.redhat.com/devel/candidates/JBEAP/) mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Djbossts.noJTA -Dtest=JMSProxyMdbMessagingServerCrashRecoveryTestCase#haltConnectionAfterDbCommits {code} was: The behavior could be observed when jts test is run in crashrec testsuite {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... (downloadable at http://download.eng.brq.redhat.com/devel/candidates/JBEAP/) mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Djbossts.noJTA -Dtest=JMSProxyMdbMessagingServerCrashRecoveryTestCase#haltConnectionAfterDbCommits {code} > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Recovery > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:39:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 06:39:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2781) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved WFLY-6748 to JBTM-2781: ------------------------------------------- Project: JBoss Transaction Manager (was: WildFly) Key: JBTM-2781 (was: WFLY-6748) Component/s: Transaction Core (was: Transactions) Affects Version/s: (was: 8.2.0.Final) > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2781 > URL: https://issues.jboss.org/browse/JBTM-2781 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 06:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2781) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2781: -------------------------------- Fix Version/s: 5.3.5.Final > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2781 > URL: https://issues.jboss.org/browse/JBTM-2781 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 06:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2781) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2781: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2781 > URL: https://issues.jboss.org/browse/JBTM-2781 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 06:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 06:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2781) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2781. ------------------------------- > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2781 > URL: https://issues.jboss.org/browse/JBTM-2781 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 12:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 12:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1085 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic > ----------------------------------------------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log > > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > ad 1. > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > ad 2. > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 13:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 13:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2773) NPE when trying delete heuristic transaction (with CMR resource) from JDBC tx log-store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2773. ------------------------------- Resolution: Duplicate Issue is incorporated by JBTM-2769 > NPE when trying delete heuristic transaction (with CMR resource) from JDBC tx log-store > --------------------------------------------------------------------------------------- > > Key: JBTM-2773 > URL: https://issues.jboss.org/browse/JBTM-2773 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.5.Final > Reporter: Daniel Simko > Assignee: Tom Jenkinson > Priority: Critical > > Part of the test is cleaning tx log-store: > {code} > 14:36:46,747 ERROR [org.jboss.as.test.jbossts.base.setup.operations.TMOperations] (main) Management operation { > "operation" => "delete", > "address" => [ > ("subsystem" => "transactions"), > ("log-store" => "log-store"), > ("transactions" => "0:ffff7f000001:-475b5c9c:5804af44:31") > ] > } failed: { > "outcome" => "failed", > "failure-description" => "java.lang.NullPointerException", > "rolled-back" => true > } > {code} > but fails with NPE. Server log: > {code} > 2016-10-17 14:36:42,798 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:42,798 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:43,140 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:43,140 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::BasicAction(0:ffff7f000001:-475b5c9c:5804af44:31) > 2016-10-17 14:36:43,141 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::activate() for action-id 0:ffff7f000001:-475b5c9c:5804af44:31 > 2016-10-17 14:36:43,308 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:43,474 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::restore_state () > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager.unpackHeader for object-id 0:ffff7f000001:-475b5c9c:5804af44:31 birth-date 1476707800081 > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Unpacked a 463 record > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked heuristic list size of 1 > 2016-10-17 14:36:43,475 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) Transaction 0:ffff7f000001:-475b5c9c:5804af44:31 has 1 heuristic participant(s)! > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked a 50 record > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:0:0:0:0 ) > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) AbstractRecord::AbstractRecord () - crash recovery constructor > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecord.CommitMarkableResourceRecord (), record id=-8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) unpack: java:jboss/xa-datasources/CrashRecoveryDS > 2016-10-17 14:36:43,475 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) unpack: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-475b5c9c:5804af44:31, node_name=1, branch_uid=0:ffff7f000001:-475b5c9c:5804af44:37, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > > 2016-10-17 14:36:43,476 TRACE [com.arjuna.ats.jta] (management-handler-thread - 4) TransactionSynchronizationRegistryImple.getTransactionKey > 2016-10-17 14:36:43,476 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Attempting to delete number of entries: 2 > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) CommitMarkableResourceRecordRecoveryModule::connecting to: java:jboss/xa-datasources/CrashRecoveryDS > 2016-10-17 14:36:43,991 TRACE [com.arjuna.ats.jta] (management-handler-thread - 4) TransactionSynchronizationRegistryImple.getTransactionKey > 2016-10-17 14:36:44,334 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:44,335 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:44,669 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions > 2016-10-17 14:36:44,669 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:44,669 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:45,002 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState() > 2016-10-17 14:36:45,002 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) OutputObjectState::OutputObjectState() > 2016-10-17 14:36:45,838 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:46,004 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:46,004 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) BasicAction::BasicAction(0:ffff7f000001:-475b5c9c:5804af44:31) > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager.unpackHeader for object-id 0:ffff7f000001:-475b5c9c:5804af44:31 birth-date 1476707800081 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) wasCommitted< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:-475b5c9c:5804af44:31, node_name=1, branch_uid=0:ffff7f000001:-475b5c9c:5804af44:37, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > null > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/CommitMarkableResourceRecord for -8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 > 2016-10-17 14:36:46,005 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) Transaction 0:ffff7f000001:-475b5c9c:5804af44:31 restored heuristic participant com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord at 2493dae0 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) HeuristicList - Unpacked a 463 record > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored action status of ActionStatus.COMMITTED 7 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored action type Top-level 0 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Restored heuristic decision of TwoPhaseOutcome.HEURISTIC_ROLLBACK 3 > 2016-10-17 14:36:46,005 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::StateManager( 0:ffff7f000001:-475b5c9c:5804af44:31 ) > 2016-10-17 14:36:46,174 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) InputObjectState::InputObjectState(0:ffff7f000001:-475b5c9c:5804af44:31, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) > 2016-10-17 14:36:46,344 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::activate( null) for object-id 0:0:0:0:0 > 2016-10-17 14:36:46,345 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) StateManager::setupStore ( null ) > 2016-10-17 14:36:46,682 WARN [com.arjuna.ats.arjuna] (management-handler-thread - 4) ARJUNA012035: Activate of object with id = 0:0:0:0:0 and type /StateManager/AbstractRecord/CommitMarkableResourceRecord unexpectedly failed > 2016-10-17 14:36:46,682 TRACE [com.arjuna.ats.arjuna] (management-handler-thread - 4) Registering: jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31 > 2016-10-17 14:36:46,682 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) registering bean jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31 > 2016-10-17 14:36:46,683 DEBUG [com.arjuna.ats.arjuna] (management-handler-thread - 4) registering bean jboss.jta:type=ObjectStore,itype=StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction,uid=0_ffff7f000001_-475b5c9c_5804af44_31,puid=-8000000000000000_-8000000000000000_-80000000_-80000000_-80000000 > {code} > Test passed for EAP 7.1.0.DR5 but failed for EAP 7.1.0.DR6. For another types of log-store (standard file based, activemq artemis journal) test passed. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 17:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 27 Oct 2016 17:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2780) JTS recovery does not process commit when connection is halt during 2PC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2780. ------------------------------- Resolution: Duplicate Issue > JTS recovery does not process commit when connection is halt during 2PC > ----------------------------------------------------------------------- > > Key: JBTM-2780 > URL: https://issues.jboss.org/browse/JBTM-2780 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Recovery > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Attachments: .jts_haltConnectionAfterDbCommits_server.log.syntax, haltConnectionAfterDbCommits_standalone-full.xml > > > I experience wrong behavior of JTS implementation in following test scenario. This seems to be a regression against behavior of recovery for 7.0.0.GA. > # there is two jboss eap 7.1.0.DR6 servers used. First deploys MDB and does periodic recovery. Second is used only as a Artemis messaging broker. > # first app server receives a message via MDB #onMessage from artemis broker (second eap server) > # during onMessage processing a enw message is send to different remote queue on artemis broker > # testing XA resource is enlisted to txn > # prepare phase passes for all 3 resources - mdb inbound, outbound queue, test xa resource > # connection to the second server is halt at time when commit message of MDB resource is sent to artemis broker but the confirmation is not delivered back to TM > # commit of MDB as xa resource and outbound queue as resource fail - XAException.XA_RETRY is returned > # the test XAResource is committed > # recovery starts work and log shows that XAResourceRecord.commit is called at some point of time but the real commit on the XAResource is not done and transaction is rolled back at the end > The expected behavior (and what I can observe for JTA as well) is that recovery process should commit the outbound connection resource (MDB resource should be committed just not confirmed back from artemis broker to TM). -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Thu Oct 27 22:26:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 27 Oct 2016 22:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2779) Add licence file to missing quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #179 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add licence file to missing quickstarts > --------------------------------------- > > Key: JBTM-2779 > URL: https://issues.jboss.org/browse/JBTM-2779 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > There are a lot of quickstarts that do not have the expected licence declarations at the top of their files. > You can find these: > find . -type f | grep -v git | grep -v jar | grep -v tools | xargs grep -H -c 'Lesser\|LICENSE-2' | grep 0$ | cut -d':' -f1 | wc > The correct licence should be added to them, you may find it easy to cat a licence file (in the correct .java, .xml, .sh, .bat format) to them. > The licence is LGPL. Those that were originally ASL etc should remain that way. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:11:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) CMR resource calls xa_forget on local resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2769: -------------------------------- Summary: CMR resource calls xa_forget on local resources (was: Inconsistent behavior of CMR resource: CommitMarkableResourceRecord#forgetHeuristic) > CMR resource calls xa_forget on local resources > ----------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Attachments: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log, JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log > > > I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. > I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). > ad 1. > * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit > This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. > This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. > ad 2. > * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted > The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) CMR resource calls xa_forget on local resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2769: -------------------------------- Description: {code} 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) {code} A local resource will have no concept of the forget and indeed the app server has an implementation that throws an exception if you call it. was: I can observe inconsistent behaviour of CMR resource against behavior of EAP 7.1.0.DR5 (Narayana 5.3.3.Final). The errors seem to come from implementation of method {{CommitMarkableResourceRecord#forgetHeuristic}}. I have two tests which fails under crash recovery testsuite and causes regression against behaviour of 7.0.0.GA (if tests are not wrong in some way). ad 1. * JPAInjectedFailureCMRTestCase#injectFailOnCMRResourceCommit This scenario injects throwing {{javax.resource.ResourceException}} at method {{javax.resource.spi.LocalTransaction#commit}}. When {{BasicAction#doForget}} is called there is thrown an {{LocalXAException}} from {{LocalXAResourceImpl}} and that's came to fact that method {{BasicAction#updateState}} does not call {{transactionStore.remove_committed}} and store is not cleaned. This is not clear integration test as exception is injected arbitrarily but at my current knowledge I don't find anything wrong with the test. ad 2. * JPAProxyCMRCrashRecoveryTestCase#prepareHaltExitRecoveryProxyHalted The second one is integration test where app server is crashed after 2PC prepare is finished. After restart is expected that both XA resources are rolled-back. When CMR is going to be a {{NullPointerException}} is thrown. {code} 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) {code} > CMR resource calls xa_forget on local resources > ----------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} > A local resource will have no concept of the forget and indeed the app server has an implementation that throws an exception if you call it. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) CMR resource calls xa_forget on local resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2769: -------------------------------- Attachment: (was: JPAProxyCMRCrashRecoveryTestCase_prepareHaltExitRecoveryProxyHalted_jta_server.log) > CMR resource calls xa_forget on local resources > ----------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} > A local resource will have no concept of the forget and indeed the app server has an implementation that throws an exception if you call it. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) CMR resource calls xa_forget on local resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2769: -------------------------------- Attachment: (was: JPAInjectedFailureCMRTestCase_injectFailOnCMRResourceCommit_jta_server.log) > CMR resource calls xa_forget on local resources > ----------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} > A local resource will have no concept of the forget and indeed the app server has an implementation that throws an exception if you call it. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:14:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Summary: JCA inflowed JTS transactions can throw NPE (was: JTS: EIS can't recover transaction when heuristic outcome happens) > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario > {quote} > * test client sends prepare command > * test client sends commit command > * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start > * test client gets error code {{XAException#XA_HEURMIX}} > * now the transaction participant is in heuristic state > * tried to commit the created txn -> fails as in heuristic and can't be operated > * using {{:recover}} command for the transaction participant > * tried to commit the txn -> expecting the commit succeed and txn is committed > {quote} > There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. > Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > [2] > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => undefined > } > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => true, > "type" => "default", > "transactions" => { > "0:ffff7f000001:3716dcba:57f50b7d:14" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", > "jmx-name" => undefined, > "type" => "Recovery/FactoryContact", > "participants" => undefined > }, > "0:ffff7f000001:3716dcba:57f50b7d:28" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => undefined > }, > "0:ffff52e38d0c:c91:4140398c:0" => { > "age-in-seconds" => undefined, > "id" => "0:ffff52e38d0c:c91:4140398c:0", > "jmx-name" => undefined, > "type" => "RecoveryCoordinator", > "participants" => undefined > } > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:14:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Steps to Reproduce: (was: Crashrecovery testsuite could be used for reproducing the issue {{mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTA -Dtest=JcaInflowTransactionTestCase#rmerrWithRecovery}}) > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario > {quote} > * test client sends prepare command > * test client sends commit command > * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start > * test client gets error code {{XAException#XA_HEURMIX}} > * now the transaction participant is in heuristic state > * tried to commit the created txn -> fails as in heuristic and can't be operated > * using {{:recover}} command for the transaction participant > * tried to commit the txn -> expecting the commit succeed and txn is committed > {quote} > There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. > Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > [2] > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => undefined > } > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => true, > "type" => "default", > "transactions" => { > "0:ffff7f000001:3716dcba:57f50b7d:14" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", > "jmx-name" => undefined, > "type" => "Recovery/FactoryContact", > "participants" => undefined > }, > "0:ffff7f000001:3716dcba:57f50b7d:28" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => undefined > }, > "0:ffff52e38d0c:c91:4140398c:0" => { > "age-in-seconds" => undefined, > "id" => "0:ffff52e38d0c:c91:4140398c:0", > "jmx-name" => undefined, > "type" => "RecoveryCoordinator", > "participants" => undefined > } > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:14:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Attachment: (was: JcaInflowTransactionTestCase_rmerrWithRecovery_jts_server.log) > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario > {quote} > * test client sends prepare command > * test client sends commit command > * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start > * test client gets error code {{XAException#XA_HEURMIX}} > * now the transaction participant is in heuristic state > * tried to commit the created txn -> fails as in heuristic and can't be operated > * using {{:recover}} command for the transaction participant > * tried to commit the txn -> expecting the commit succeed and txn is committed > {quote} > There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. > Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > [2] > {code} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => false, > "type" => "default", > "transactions" => undefined > } > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() > {"outcome" => "success"} > [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) > { > "outcome" => "success", > "result" => { > "expose-all-logs" => true, > "type" => "default", > "transactions" => { > "0:ffff7f000001:3716dcba:57f50b7d:14" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", > "jmx-name" => undefined, > "type" => "Recovery/FactoryContact", > "participants" => undefined > }, > "0:ffff7f000001:3716dcba:57f50b7d:28" => { > "age-in-seconds" => undefined, > "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", > "jmx-name" => undefined, > "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", > "participants" => undefined > }, > "0:ffff52e38d0c:c91:4140398c:0" => { > "age-in-seconds" => undefined, > "id" => "0:ffff52e38d0c:c91:4140398c:0", > "jmx-name" => undefined, > "type" => "RecoveryCoordinator", > "participants" => undefined > } > } > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:16:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Description: If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller. [1] {code} 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) ?at java.lang.Thread.run(Thread.java:745) ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} was: I hit a trouble similar to JBEAP-5638 but in this case for {{JTS}}. I'm not able to recover heuristic transaction for scenario {quote} * test client sends prepare command * test client sends commit command * first XAResource commits, secondXAResource throws {{XAException#XAER_RMERR}} on commit start * test client gets error code {{XAException#XA_HEURMIX}} * now the transaction participant is in heuristic state * tried to commit the created txn -> fails as in heuristic and can't be operated * using {{:recover}} command for the transaction participant * tried to commit the txn -> expecting the commit succeed and txn is committed {quote} There are two troubles. First is {{NullPointerException}} is thrown during a try to commit transaction in heuristic state [1]. Second is not possible to read transaction participant from object store via {{jboss-cli}} commands (even when {{expose-all-logs}} is used) and that way it's not possible to call {{recover}} the participant in heuristic state. [1] {code} 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) ?at java.lang.Thread.run(Thread.java:745) ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} [2] {code} [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) { "outcome" => "success", "result" => { "expose-all-logs" => false, "type" => "default", "transactions" => undefined } } [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs, value=true) { "outcome" => "success", "result" => undefined } [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:probe() {"outcome" => "success"} [standalone at localhost:42042 /] /subsystem=transactions/log-store=log-store:read-resource(recursive=true, include-runtime=true) { "outcome" => "success", "result" => { "expose-all-logs" => true, "type" => "default", "transactions" => { "0:ffff7f000001:3716dcba:57f50b7d:14" => { "age-in-seconds" => undefined, "id" => "0:ffff7f000001:3716dcba:57f50b7d:14", "jmx-name" => undefined, "type" => "Recovery/FactoryContact", "participants" => undefined }, "0:ffff7f000001:3716dcba:57f50b7d:28" => { "age-in-seconds" => undefined, "id" => "0:ffff7f000001:3716dcba:57f50b7d:28", "jmx-name" => undefined, "type" => "StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple/ServerTransaction/JCA", "participants" => undefined }, "0:ffff52e38d0c:c91:4140398c:0" => { "age-in-seconds" => undefined, "id" => "0:ffff52e38d0c:c91:4140398c:0", "jmx-name" => undefined, "type" => "RecoveryCoordinator", "participants" => undefined } } } } {code} > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:17:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Comment: was deleted (was: This is the same testcase as in {{JBTM-2734}} and it passes for JTA. I'm not 100% sure if there is not needed a special handling for JTS. Especially the trouble of getting participants of transaction seems to me strange.) > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Summary: Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed (was: Inconsistent behavior of CMR resource: XARecoveryModule#getNewXAResource) > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log > > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Steps to Reproduce: (was: {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... (downloadable at http://download.eng.brq.redhat.com/devel/candidates/JBEAP/) DS_PROPS="-Dds0.db=oracle -Dds0.jdbc.driver.url=http://www.qa.jboss.com/jdbc-drivers-products/EAP/7.1.0/oracle12c/jdbc4/ojdbc7.jar -Dds0.jdbc.xa-class=oracle.jdbc.xa.client.OracleXADataSource -Dds0.jdbc.url=jdbc:oracle:thin:@dev151.mw.lab.eng.bos.redhat.com:1521:qaora12 -Dds0.db.name=qaora12 -Dds0.user=crashrec -Dds0.pass=crashrec -Dds0.jdbc.driver.jar=dsdriver-oracle.jar" mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JPAProxyCMRCrashRecoveryTestCase#commitHaltRecoveryProxyHalted $DS_PROPS {code}) > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log > > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Attachment: (was: JPAProxyCMRCrashRecoveryTestCase_commitHaltRecoveryProxyHalted_jta_server.log) > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > > I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) > The scenario which I run is following > {quote} > * enlist test xa resource > * enlist cmr db resource > * prepare cmr db resource > * prepare test xa resource > * commit cmr db resource > * crash app server > * start server and halt connection to DB > * do recovery of test xa resource which is expected being committed > {quote} > What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). > In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. > {code} > 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Fix Version/s: 5.next > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > During recovery the CMR orphan detection checks to make sure that there is not an indoubt transaction that pertains to the CMR before deciding if an Xid is an orphan. Actually the check should also see if the transaction committed. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Description: During recovery the CMR orphan detection checks to make sure that there is not an indoubt transaction that pertains to the CMR before deciding if an Xid is an orphan. Actually the check should also see if the transaction committed. (was: I found another regression (besides JBEAP-6326) for behavior of CMR datasource which came with DR6 (Narayana 5.3.5.Final) and is regression against DR5 (5.3.3.Final) The scenario which I run is following {quote} * enlist test xa resource * enlist cmr db resource * prepare cmr db resource * prepare test xa resource * commit cmr db resource * crash app server * start server and halt connection to DB * do recovery of test xa resource which is expected being committed {quote} What happens is that the second resource (test XA resource) is not committed but is rolled-back. By my investigation I think that the regression came from changes under {{com.arjuna.ats.internal.jta.recovery.arjunacore#getNewXAResource(Xid xid)}} (but it's only observation and it could be wrong interpretation). In log the rollback could be seen being caused by {{JTANodeNameXAResourceOrphanFilter}} which votes for rollback. {code} 2016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:4302bcff:57f67425:2a, node_name=1, branch_uid=0:ffff7f000001:4302bcff:57f67425:2f, subordinatenodename=null, eis_name=java:/TestXAResource > is 12016-10-06 17:59:19,552 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK {code}) > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > During recovery the CMR orphan detection checks to make sure that there is not an indoubt transaction that pertains to the CMR before deciding if an Xid is an orphan. Actually the check should also see if the transaction committed. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Fix Version/s: 5.next > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2769) CMR resource calls xa_forget on local resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2769: -------------------------------- Fix Version/s: 5.next > CMR resource calls xa_forget on local resources > ----------------------------------------------- > > Key: JBTM-2769 > URL: https://issues.jboss.org/browse/JBTM-2769 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > {code} > 2016-10-06 17:50:17,105 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012290: failed to recover Transaction 0:ffff7f000001:6351fff9:57f67185:2a: java.lang.NullPointerException > at com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord.forgetHeuristic(CommitMarkableResourceRecord.java:544) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doForget(BasicAction.java:3603) > at com.arjuna.ats.arjuna.coordinator.BasicAction.forgetHeuristics(BasicAction.java:1347) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1991) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:2852) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:1871) > at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:71) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:152) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253) > at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:811) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377) > {code} > A local resource will have no concept of the forget and indeed the app server has an implementation that throws an exception if you call it. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2767) JCA inflowed JTS transactions can throw NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2767: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1085/commits > JCA inflowed JTS transactions can throw NPE > ------------------------------------------- > > Key: JBTM-2767 > URL: https://issues.jboss.org/browse/JBTM-2767 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > If an XAResource throws a heuristic we can't forget it but we do clean up some transactional state meaning it will need reloading from disk (after the heuristic is cleared) before it can be meaningfully used again. In the state where it can't be meaningfully used we need to provide something to the caller. > [1] > {code} > 2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) java.lang.NullPointerException2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? > at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.SubordinateAtomicTransaction.getXid(SubordinateAtomicTransaction.java:80)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.baseXid(TransactionImple.java:126)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1)? at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:135)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at java.lang.Thread.run(Thread.java:745)2016-10-05 16:19:23,537 ERROR [stderr] (default-threads - 1) > ? at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 2016-10-05 16:19:23,538 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Unspecified sever exception: java.lang.NullPointerException?at com.arjuna.ats.internal.jta.transaction.jts.subordinate.jca.TransactionImple.recover(TransactionImple.java:135) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.TransactionImporterImple.getImportedTransaction(TransactionImporterImple.java:141) > ?at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.commit(XATerminatorImple.java:83)?at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)?at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223) > ?at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)?at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > ?at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > ?at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > ?at java.lang.Thread.run(Thread.java:745) > ?at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS works incorrectly for JMS connection being interrupted at commit phase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2771: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1085/ > JTS works incorrectly for JMS connection being interrupted at commit phase > -------------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2770) Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2770: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1085/ > Xids that relate to an CMR that has been recovered are rolledback even if the CMR committed > ------------------------------------------------------------------------------------------- > > Key: JBTM-2770 > URL: https://issues.jboss.org/browse/JBTM-2770 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > During recovery the CMR orphan detection checks to make sure that there is not an indoubt transaction that pertains to the CMR before deciding if an Xid is an orphan. Actually the check should also see if the transaction committed. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:24:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2771: -------------------------------- Summary: JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried (was: JTS works incorrectly for JMS connection being interrupted at commit phase) > JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried > -------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. > The following scenario fails when JTS is used > {quote} > * prepare jms XA > * stop connection to jms broker > * prepare test XA > * call commit on jms XA > as connection is down we can experience {{XAException.XA_RETRY}} > * commit test XA > (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) > * recovery: commit jms XA > {quote} > in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. > {code} > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 > 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 > 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() > 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) > 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] > 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) > 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] > 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) > 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true > 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false > 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed > {code} -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:30:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2771: -------------------------------- Description: There is a flag that is persisted _committed which defines if a commit was attempted on an XAResource. In the case where the XAR returned XARETRY for example, we would have consulted that flag and not reattempted the commit. (was: I do experience regression against DR5 (Narayana 5.3.3.Final) with current DR6 (Narayana 5.3.5.Final) release. The following scenario fails when JTS is used {quote} * prepare jms XA * stop connection to jms broker * prepare test XA * call commit on jms XA as connection is down we can experience {{XAException.XA_RETRY}} * commit test XA (the test XA is committed as XA_RETRY commands to finish the commit later which is made by recovery) * recovery: commit jms XA {quote} in 7.1.0.DR6 version the recovery does not {{commit}} but {{rollback}} which can cause data integrity failure. {code} 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( getStatus ) nodeId=1 requestId=135 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( getStatus ) nodeId=1 requestId=135 2016-10-11 17:03:32,194 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( getStatus ) nodeId=1 requestId=132 2016-10-11 17:03:32,194 DEBUG [com.arjuna.ats.jts] (Periodic Recovery) StatusChecker.getStatus(0:ffff7f000001:-687fd072:57fcfee8:4f) - stored status = CosTransactions::StatusNoTransaction 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::send_reply ( replay_completion ) nodeId=1 requestId=133 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionServerRequestInterceptorImpl::suspendContext ( replay_completion ) nodeId=1 requestId=133 2016-10-11 17:03:32,195 DEBUG [com.arjuna.ats.jts] (Thread-276) ResourceCompletor.rollback() 2016-10-11 17:03:32,195 TRACE [com.arjuna.ats.jts] (Periodic Recovery) InterpositionClientRequestInterceptorImpl::receive_reply ( replay_completion ) nodeId=1 requestId=130 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionClientRequestInterceptorImpl::send_request ( rollback ) nodeId=1 requestId=133 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.recover got status: CosTransactions::StatusRolledBack 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) ContextManager::current () 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.doRecovery ( false ) 2016-10-11 17:03:32,196 INFO [com.arjuna.ats.jtax] (Periodic Recovery) ARJUNA024002: XA recovery rolling back < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Periodic Recovery) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( rollback ) nodeId=1 requestId=136 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jts] (Thread-276) InterpositionServerRequestInterceptorImpl::receive_request ( rollback ) nodeId=1 requestId=136 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Periodic Recovery) Calling rollback:: xid=XidImpl (948004762 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [com.arjuna.ats.jtax] (Thread-276) XAResourceRecord.rollback for < 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,196 TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl] (Thread-276) Calling rollback:: xid=XidImpl (1942398309 bq:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.84.0.0.0.0.0.0.0.0 formatID:131072 gtxid:0.0.0.0.0.0.0.0.0.0.-1.-1.127.0.0.1.-105.-128.47.-114.87.-4.-2.-24.0.0.0.79.49 base64:AAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAAVAAAAAAAAAAAAAAAAAAAAAAAAP__fwAAAZeAL45X_P7oAAAATzECAgIA,clientXID=< 131072, 29, 36, 0000000000-1-1127001-105-12847-11487-4-2-240007949, 0000000000-1-1127001-105-12847-11487-4-2-240008400000000 > 2016-10-11 17:03:32,197 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Periodic Recovery) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] 2016-10-11 17:03:32,240 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (Thread-3 (ActiveMQ-client-netty-threads-2140185711)) handling packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponseMessage] 2016-10-11 17:03:32,241 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HornetqObjectStore.remove_committed(0:ffff7f000001:-687fd072:57fcfee8:55, /CosTransactions/XAResourceRecord) 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.journal.impl.JournalImpl] (Periodic Recovery) appendDeleteRecord::id=1, usedFile = JournalFileImpl: (jbossts-1.txlog id = 1, recordID = 1) 2016-10-11 17:03:32,241 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl] (Thread-276) Sending blocking PACKET(SessionXARollbackMessage)[type=56, channelID=10, packetObject=SessionXARollbackMessage] 2016-10-11 17:03:32,247 TRACE [com.arjuna.orbportability] (Periodic Recovery) RootOA::shutdownObject (Servant) 2016-10-11 17:03:32,248 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext at 4b366010, receiver=org.jboss.as.ejb3.remote.LocalEjbReceiver at 5db75d15}, transactionOriginNodeIdentifier='1'} 1476198202113 1476198212248 false 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:473, xid:null, timeout:0, prepareReturn:0)) 1476198162076 1476198212248 true 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 16b79fd1 1476198161776 1476198212251 true 2016-10-11 17:03:32,251 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 130c1cb1 1476198202161 1476198212251 false 2016-10-11 17:03:32,251 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) JTS XARecoveryModule.resourceInitiatedRecovery completed {code}) > JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried > -------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > There is a flag that is persisted _committed which defines if a commit was attempted on an XAResource. In the case where the XAR returned XARETRY for example, we would have consulted that flag and not reattempted the commit. -- This message was sent by Atlassian JIRA (v7.2.2#72004) From issues at jboss.org Fri Oct 28 12:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 28 Oct 2016 12:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2771) JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2771: -------------------------------- Steps to Reproduce: (was: {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... (downloadable at http://download.eng.brq.redhat.com/devel/candidates/JBEAP/) mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Djbossts.noJTA -Dtest=JMSProxyMessagingServerCrashRecoveryTestCase#prepareHalt {code}) > JTS XAResources that throw XA_RETRY or XAER_RMFAIL cannot be retried > -------------------------------------------------------------------- > > Key: JBTM-2771 > URL: https://issues.jboss.org/browse/JBTM-2771 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.5.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Blocker > Attachments: JMSProxyMessagingServerCrashRecoveryTestCase_prepareHalt_jts_server.log > > > There is a flag that is persisted _committed which defines if a commit was attempted on an XAResource. In the case where the XAR returned XARETRY for example, we would have consulted that flag and not reattempted the commit. -- This message was sent by Atlassian JIRA (v7.2.2#72004)