From issues at jboss.org Mon Jun 1 03:22:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Jun 2015 03:22:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2425: -------------------------------------- Summary: Upgrade to latest wildfly version Key: JBTM-2425 URL: https://issues.jboss.org/browse/JBTM-2425 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 06:46:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Jun 2015 06:46:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2425: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/857 > Upgrade to latest wildfly version > --------------------------------- > > Key: JBTM-2425 > URL: https://issues.jboss.org/browse/JBTM-2425 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 1 06:46:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 1 Jun 2015 06:46:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2425: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to latest wildfly version > --------------------------------- > > Key: JBTM-2425 > URL: https://issues.jboss.org/browse/JBTM-2425 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 00:23:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 2 Jun 2015 00:23:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13072945#comment-13072945 ] Amos Feng commented on JBTM-2420: --------------------------------- It looks like related to the directory separator and the btadmin can not start the test process. btadmin/src/test/resources/btconfig.xml {code} {code} > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/918/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 2 11:48:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 2 Jun 2015 11:48:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2404) narayana-codeCoverage CI job is not producing any output In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073302#comment-13073302 ] Michael Musgrove commented on JBTM-2404: ---------------------------------------- It is failing again on JDK 8 (http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-codeCoverage/214) Note that it did work initially on JDK 8 (eg http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-codeCoverage/209/) > narayana-codeCoverage CI job is not producing any output > -------------------------------------------------------- > > Key: JBTM-2404 > URL: https://issues.jboss.org/browse/JBTM-2404 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The job config fails to produce the report if we don't run any qa tests during a build. See the following job for example: > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/194/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 04:14:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 3 Jun 2015 04:14:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2420: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/860 > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/918/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 05:27:03 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 3 Jun 2015 05:27:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2295) Expose REST-TX (and WS-TX) endpoints through Docker In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2295: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Expose REST-TX (and WS-TX) endpoints through Docker > --------------------------------------------------- > > Key: JBTM-2295 > URL: https://issues.jboss.org/browse/JBTM-2295 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, REST, XTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 3 08:38:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 3 Jun 2015 08:38:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2407) Remove CDIExtensionProcessor in the XTS subsytem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2407: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove CDIExtensionProcessor in the XTS subsytem > ------------------------------------------------ > > Key: JBTM-2407 > URL: https://issues.jboss.org/browse/JBTM-2407 > Project: JBoss Transaction Manager > Issue Type: Task > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > WFLY-1370 removes the need for the CDIExtensionProcessor in the XTS subsytem. > There is currently a hack in CDIExtensionProcessor in 5_BRANCH. This MUST be removed if WFLY-1370 is not merged in time for release. Hence I have marked this as critical. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 4 05:54:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 4 Jun 2015 05:54:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2408) Remove CDI extension descriptors from compensations quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2408: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/141 > Remove CDI extension descriptors from compensations quickstarts > --------------------------------------------------------------- > > Key: JBTM-2408 > URL: https://issues.jboss.org/browse/JBTM-2408 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 4 10:22:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Jun 2015 10:22:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2404) narayana-codeCoverage CI job is not producing any output In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2404: ----------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/845, https://github.com/jbosstm/narayana/pull/862 (was: https://github.com/jbosstm/narayana/pull/845) Added another PR because: JBTM-1339 copied the openjdk-orb jar to the build directory but this causes jacoco to try to instrument it. I have changed the pom so that the jar is now referenced via the local maven repository. > narayana-codeCoverage CI job is not producing any output > -------------------------------------------------------- > > Key: JBTM-2404 > URL: https://issues.jboss.org/browse/JBTM-2404 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The job config fails to produce the report if we don't run any qa tests during a build. See the following job for example: > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/194/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 4 13:25:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 4 Jun 2015 13:25:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2426) XTS WSTFSC07-interop failure In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2426: -------------------------------------- Summary: XTS WSTFSC07-interop failure Key: JBTM-2426 URL: https://issues.jboss.org/browse/JBTM-2426 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Affects Versions: 5.1.1 Reporter: Michael Musgrove Assignee: Gytis Trikleris junit test failure: {code} Running com.jboss.transaction.wstf.interop.Sc007Test Tests run: 15, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 326.369 sec <<< FAILURE! test3_10(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 212.002 sec <<< FAILURE! junit.framework.AssertionFailedError: Conversation did not complete successfully at junit.framework.Assert.fail(Assert.java:57) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.TestCase.assertTrue(TestCase.java:192) at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_10(Sc007TestCase.java:474) at com.jboss.transaction.wstf.interop.Sc007Test.test3_10(Sc007Test.java:176) test3_11(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 1.608 sec <<< ERROR! com.arjuna.wst.TransactionRolledBackException: null at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_11(Sc007TestCase.java:495) at com.jboss.transaction.wstf.interop.Sc007Test.test3_11(Sc007Test.java:181) Results : Failed tests: Sc007Test.test3_10:176 Conversation did not complete successfully Tests in error: Sc007Test.test3_11:181 ? TransactionRolledBack {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 04:09:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 5 Jun 2015 04:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2308: ------------------------------------ I am reopening because the participants of these transaction types are not being instrumented. > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 04:18:04 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 5 Jun 2015 04:18:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2426) XTS WSTFSC07-interop failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2426: ---------------------------------- Attachment: com.jboss.transaction.wstf.interop.Sc007Test-output.txt > XTS WSTFSC07-interop failure > ---------------------------- > > Key: JBTM-2426 > URL: https://issues.jboss.org/browse/JBTM-2426 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Attachments: com.jboss.transaction.wstf.interop.Sc007Test-output.txt > > > junit test failure: > {code} > Running com.jboss.transaction.wstf.interop.Sc007Test > Tests run: 15, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 326.369 sec <<< FAILURE! > test3_10(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 212.002 sec <<< FAILURE! > junit.framework.AssertionFailedError: Conversation did not complete successfully > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_10(Sc007TestCase.java:474) > at com.jboss.transaction.wstf.interop.Sc007Test.test3_10(Sc007Test.java:176) > test3_11(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 1.608 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_11(Sc007TestCase.java:495) > at com.jboss.transaction.wstf.interop.Sc007Test.test3_11(Sc007Test.java:181) > Results : > Failed tests: > Sc007Test.test3_10:176 Conversation did not complete successfully > Tests in error: > Sc007Test.test3_11:181 ? TransactionRolledBack > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 05:03:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 5 Jun 2015 05:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13074552#comment-13074552 ] Michael Musgrove commented on JBTM-2308: ---------------------------------------- Note that the junit tests for this work only asserted the creation of MBeans for the top level log and is the reason why our testing produced a false positive. The fix needs to make sure that the tests also assert the presents of MBeans for the participants. > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 05:46:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 5 Jun 2015 05:46:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13074552#comment-13074552 ] Michael Musgrove edited comment on JBTM-2308 at 6/5/15 5:45 AM: ---------------------------------------------------------------- Note that the junit tests for this work only asserted the creation of MBeans for the top level log and is the reason why our testing produced a false positive. The fix needs to make sure that the tests also assert the presence of MBeans for the participants. was (Author: mmusgrov): Note that the junit tests for this work only asserted the creation of MBeans for the top level log and is the reason why our testing produced a false positive. The fix needs to make sure that the tests also assert the presents of MBeans for the participants. > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 5 08:37:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 5 Jun 2015 08:37:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2426) XTS WSTFSC07-interop failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2426: ---------------------------------- Priority: Minor (was: Major) > XTS WSTFSC07-interop failure > ---------------------------- > > Key: JBTM-2426 > URL: https://issues.jboss.org/browse/JBTM-2426 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Gytis Trikleris > Priority: Minor > Attachments: com.jboss.transaction.wstf.interop.Sc007Test-output.txt > > > junit test failure: > {code} > Running com.jboss.transaction.wstf.interop.Sc007Test > Tests run: 15, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 326.369 sec <<< FAILURE! > test3_10(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 212.002 sec <<< FAILURE! > junit.framework.AssertionFailedError: Conversation did not complete successfully > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_10(Sc007TestCase.java:474) > at com.jboss.transaction.wstf.interop.Sc007Test.test3_10(Sc007Test.java:176) > test3_11(com.jboss.transaction.wstf.interop.Sc007Test) Time elapsed: 1.608 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) > at com.jboss.transaction.wstf.interop.Sc007TestCase.test3_11(Sc007TestCase.java:495) > at com.jboss.transaction.wstf.interop.Sc007Test.test3_11(Sc007Test.java:181) > Results : > Failed tests: > Sc007Test.test3_10:176 Conversation did not complete successfully > Tests in error: > Sc007Test.test3_11:181 ? TransactionRolledBack > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 03:27:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 8 Jun 2015 03:27:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2427) btadmin.ListRunningInstanceIdsTest hang on the Linux In-Reply-To: References: Message-ID: Amos Feng created JBTM-2427: ------------------------------- Summary: btadmin.ListRunningInstanceIdsTest hang on the Linux Key: JBTM-2427 URL: https://issues.jboss.org/browse/JBTM-2427 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux32el5/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 04:00:04 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 8 Jun 2015 04:00:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2427) btadmin.ListRunningInstanceIdsTest hang on the Linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075219#comment-13075219 ] Amos Feng commented on JBTM-2427: --------------------------------- It looks like related to the shutdown command which checks if the process is alive. > btadmin.ListRunningInstanceIdsTest hang on the Linux > ---------------------------------------------------- > > Key: JBTM-2427 > URL: https://issues.jboss.org/browse/JBTM-2427 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux32el5/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 04:54:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 8 Jun 2015 04:54:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2420: -------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/860, https://github.com/jbosstm/narayana/pull/863 (was: https://github.com/jbosstm/narayana/pull/860) > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/918/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 04:54:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 8 Jun 2015 04:54:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2420: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/918/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 05:01:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 8 Jun 2015 05:01:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2427) btadmin.ListRunningInstanceIdsTest hang on the Linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2427: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/864 > btadmin.ListRunningInstanceIdsTest hang on the Linux > ---------------------------------------------------- > > Key: JBTM-2427 > URL: https://issues.jboss.org/browse/JBTM-2427 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux32el5/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 05:09:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 8 Jun 2015 05:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2408) Remove CDI extension descriptors from compensations quickstarts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2408: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove CDI extension descriptors from compensations quickstarts > --------------------------------------------------------------- > > Key: JBTM-2408 > URL: https://issues.jboss.org/browse/JBTM-2408 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 8 10:11:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 8 Jun 2015 10:11:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2308: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/795, https://github.com/jbosstm/narayana/pull/796, https://github.com/jbosstm/narayana/pull/865 (was: https://github.com/jbosstm/narayana/pull/795, https://github.com/jbosstm/narayana/pull/796) > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 01:10:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 9 Jun 2015 01:10:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2420) BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075788#comment-13075788 ] Amos Feng commented on JBTM-2420: --------------------------------- the root cause looks like the case sensitivity of Path environment in the btadmin > BlackTie hanging on all windows builds during btadmin: Transaction 0:ffff0a27a80e:-6a877d1b:555c3b97:8b has 1 heuristic participant(s) > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2420 > URL: https://issues.jboss.org/browse/JBTM-2420 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, REST > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-catelyn/918/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 03:09:02 2015 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Tue, 9 Jun 2015 03:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka moved JBEAP-285 to JBTM-2428: ---------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2428 (was: JBEAP-285) Workflow: GIT Pull Request workflow (was: CDW v1) Affects Version/s: 5.1.1 (was: EAP 7.0.0.DR3) Component/s: (was: IIOP) (was: Transactions) Target Release: (was: EAP 7.0.0.GA) > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 03:10:03 2015 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Tue, 9 Jun 2015 03:10:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka reassigned JBTM-2428: -------------------------------------- Assignee: Tomasz Adamski (was: Ond?ej Chaloupka) > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Tomasz Adamski > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 05:48:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 05:48:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2427) btadmin.ListRunningInstanceIdsTest hang on the Linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2427: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > btadmin.ListRunningInstanceIdsTest hang on the Linux > ---------------------------------------------------- > > Key: JBTM-2427 > URL: https://issues.jboss.org/browse/JBTM-2427 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux32el5/ -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 05:56:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 05:56:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2308: ----------------------------------- Fix Version/s: 5.next > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0, 5.next > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 06:23:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 06:23:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2429: -------------------------------------- Summary: Disable java debugger in the surefire tests Key: JBTM-2429 URL: https://issues.jboss.org/browse/JBTM-2429 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Affects Versions: 5.1.1 Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.next We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with {code} ERROR: transport error 202: bind failed: Address already in use JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized {code} I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 06:49:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 06:49:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13075931#comment-13075931 ] Tom Jenkinson commented on JBTM-2429: ------------------------------------- I am not sure how easy this will be but is it possible to leave it as a system property where we can enable it? e.g. -DenableDebugger > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:09:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 09:09:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2265) BlackTie Jatmibroker TestTPConversation hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2265: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > BlackTie Jatmibroker TestTPConversation hang > -------------------------------------------- > > Key: JBTM-2265 > URL: https://issues.jboss.org/browse/JBTM-2265 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.0.3 > Reporter: Michael Musgrove > Assignee: Amos Feng > Fix For: 5.later > > Attachments: blacktie.zip, jstack.27403, jstack.27697 > > > CI job http://172.17.131.2/view/Narayana+BlackTie/job/narayana-dualstack/193 is hanging with what looks like a stomp comms error -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:19:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 09:19:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2404) narayana-codeCoverage CI job is not producing any output In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2404: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > narayana-codeCoverage CI job is not producing any output > -------------------------------------------------------- > > Key: JBTM-2404 > URL: https://issues.jboss.org/browse/JBTM-2404 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Configuration > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The job config fails to produce the report if we don't run any qa tests during a build. See the following job for example: > http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/194/consoleFull -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:20:07 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 09:20:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2308. ------------------------------------ Resolution: Done > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next, 5.1.0, 4.17.27 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:20:07 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 09:20:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2414) Upgrade the version of wildfly to 10.0.0.Alpha2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2414: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade the version of wildfly to 10.0.0.Alpha2 > ----------------------------------------------- > > Key: JBTM-2414 > URL: https://issues.jboss.org/browse/JBTM-2414 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:21:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 09:21:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2416) OSGiJTATest #testTransactionManager failed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2416: -------------------------------- Fix Version/s: 5.later (was: 5.next) > OSGiJTATest #testTransactionManager failed > ------------------------------------------ > > Key: JBTM-2416 > URL: https://issues.jboss.org/browse/JBTM-2416 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.later > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/837/PROFILE=MAIN,jdk=jdk8.latest,label=linux/console > {code} > Running org.jboss.narayana.osgi.jta.OSGiJTATest > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.09 sec <<< FAILURE! > testTransactionManager(org.jboss.narayana.osgi.jta.OSGiJTATest) Time elapsed: 0.003 sec <<< FAILURE! > java.lang.AssertionError: Bundle ACTIVE expected:<32> but was:<4> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.jboss.narayana.osgi.jta.OSGiJTATest.testTransactionManager(OSGiJTATest.java:81) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 09:31:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 9 Jun 2015 09:31:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2421) Provide some quickstarts for STM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2421: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide some quickstarts for STM > -------------------------------- > > Key: JBTM-2421 > URL: https://issues.jboss.org/browse/JBTM-2421 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > As part of my JBug I took the example from the documentation and produced a set of quickstarts that would be useful to contribute to the project. > The examples show: > 1. Pessimistic locking > 2. Optimistic locking > 3. Use of an STM object in a JTA transaction -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 10:16:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 10:16:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2430: -------------------------------------- Summary: Update openjdk-orb library to 8.0.4.Final Key: JBTM-2430 URL: https://issues.jboss.org/browse/JBTM-2430 Project: JBoss Transaction Manager Issue Type: Component Upgrade Reporter: Michael Musgrove Assignee: Tomasz Adamski openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 11:09:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 9 Jun 2015 11:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2429. ------------------------------------ Resolution: Done > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 11:54:04 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 9 Jun 2015 11:54:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076260#comment-13076260 ] Tomasz Adamski commented on JBTM-2430: -------------------------------------- After your fix it is no longer necessary as no runner will perform any operation after run method returns. As a result of that I decided to remove it. > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 11:54:05 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 9 Jun 2015 11:54:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076260#comment-13076260 ] Tomasz Adamski edited comment on JBTM-2430 at 6/9/15 11:53 AM: --------------------------------------------------------------- After your fix it is no longer necessary as no runner will perform any ORB operation after run method returns. As a result of that I decided to remove it. was (Author: tomekadamski): After your fix it is no longer necessary as no runner will perform any operation after run method returns. As a result of that I decided to remove it. > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 9 11:54:06 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 9 Jun 2015 11:54:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076260#comment-13076260 ] Tomasz Adamski edited comment on JBTM-2430 at 6/9/15 11:53 AM: --------------------------------------------------------------- After your fix it is no longer necessary as no runner will perform any ORB operation after run method returns. As a result of that I decided to revert it. was (Author: tomekadamski): After your fix it is no longer necessary as no runner will perform any ORB operation after run method returns. As a result of that I decided to remove it. > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Tomasz Adamski > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 05:07:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 10 Jun 2015 05:07:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2417) Create CI pull request job for narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2417: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana.io/pull/4 > Create CI pull request job for narayana.io > ------------------------------------------ > > Key: JBTM-2417 > URL: https://issues.jboss.org/browse/JBTM-2417 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 05:07:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 10 Jun 2015 05:07:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2417) Create CI pull request job for narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2417: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create CI pull request job for narayana.io > ------------------------------------------ > > Key: JBTM-2417 > URL: https://issues.jboss.org/browse/JBTM-2417 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 10:41:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Jun 2015 10:41:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2431: -------------------------------------- Summary: Arquillian failures due to version mismatches Key: JBTM-2431 URL: https://issues.jboss.org/browse/JBTM-2431 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Michael Musgrove Assignee: Tom Jenkinson We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 10:42:06 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Jun 2015 10:42:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2431: -------------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Arquillian failures due to version mismatches > --------------------------------------------- > > Key: JBTM-2431 > URL: https://issues.jboss.org/browse/JBTM-2431 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): > bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final > But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: > bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 > The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 10:54:01 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Jun 2015 10:54:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2431: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/867 > Arquillian failures due to version mismatches > --------------------------------------------- > > Key: JBTM-2431 > URL: https://issues.jboss.org/browse/JBTM-2431 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): > bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final > But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: > bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 > The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 11:31:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Jun 2015 11:31:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2409: ----------------------------------- Fix Version/s: 5.later (was: 5.next) > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 10 12:20:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 10 Jun 2015 12:20:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2431: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Arquillian failures due to version mismatches > --------------------------------------------- > > Key: JBTM-2431 > URL: https://issues.jboss.org/browse/JBTM-2431 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): > bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final > But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: > bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 > The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:02:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Jun 2015 10:02:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077539#comment-13077539 ] Gytis Trikleris commented on JBTM-2429: --------------------------------------- In WildFly testsuite there is a debug profile which can be enabled via system property > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:13:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Jun 2015 10:13:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077553#comment-13077553 ] Michael Musgrove commented on JBTM-2429: ---------------------------------------- We have quite a few profiles already so I backed away from adding to that long list. > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:33:03 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Jun 2015 10:33:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077571#comment-13077571 ] Gytis Trikleris commented on JBTM-2429: --------------------------------------- But I think it's quite convenient not having to copy and paste that long debugger configuration line every time you need it. > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:39:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Jun 2015 10:39:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077582#comment-13077582 ] Michael Musgrove commented on JBTM-2429: ---------------------------------------- I sent an email to developers about it before making the change to ensure people were happy with its removal. You may reopen and reassign the JIRA and add it back in again if you wish. > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:39:04 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Jun 2015 10:39:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077583#comment-13077583 ] Gytis Trikleris commented on JBTM-2429: --------------------------------------- Also profile wouldn't be big. Even something like that would work IMO (although enabling with system property is convenient): {code} debug false -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787 {code} > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:41:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 11 Jun 2015 10:41:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077586#comment-13077586 ] Gytis Trikleris commented on JBTM-2429: --------------------------------------- I didn't mean to reopen this one. Just to check if it's worth opening a new one (and if other people agree). > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 10:55:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 11 Jun 2015 10:55:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2429) Disable java debugger in the surefire tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077598#comment-13077598 ] Tom Jenkinson commented on JBTM-2429: ------------------------------------- I think it would be useful - yes > Disable java debugger in the surefire tests > ------------------------------------------- > > Key: JBTM-2429 > URL: https://issues.jboss.org/browse/JBTM-2429 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > We are having intermittent problems with arquillian tests on the mac that start containers one after the other. It seems that a previous one is slow to shut down causing the next one to fail to start with > {code} > ERROR: transport error 202: bind failed: Address already in use > JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized > {code} > I plan to disable the debugger (I think we enabled it because of a hang on an old issue where we needed the debugger port open to aid diagnosis). -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 12:52:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Jun 2015 12:52:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2432: -------------------------------------- Summary: Cannot test IBM J9 VM on linux Key: JBTM-2432 URL: https://issues.jboss.org/browse/JBTM-2432 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Reporter: Michael Musgrove Assignee: Tom Jenkinson Fix For: 5.later We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 17:04:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 11 Jun 2015 17:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077813#comment-13077813 ] Tom Jenkinson commented on JBTM-2432: ------------------------------------- We could cut down the build to just Narayana+QA tests and avoid the app server ones. > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 17:11:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Jun 2015 17:11:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077816#comment-13077816 ] Michael Musgrove commented on JBTM-2432: ---------------------------------------- Good plan, we will need to disable all of the tests that use arquillian loosing quite a bit of coverage but much than not testing it at all. > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 11 17:12:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 11 Jun 2015 17:12:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077816#comment-13077816 ] Michael Musgrove edited comment on JBTM-2432 at 6/11/15 5:11 PM: ----------------------------------------------------------------- Good plan, we will need to disable all of the tests that use arquillian loosing quite a bit of coverage but much better than not testing it at all. was (Author: mmusgrov): Good plan, we will need to disable all of the tests that use arquillian loosing quite a bit of coverage but much than not testing it at all. > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 08:57:02 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 12 Jun 2015 08:57:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078179#comment-13078179 ] Mark Little commented on JBTM-2432: ----------------------------------- Is there anything in Narayana that requires Java8 though? If not then why not still allow that at build time? > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 09:09:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Jun 2015 09:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078189#comment-13078189 ] Michael Musgrove commented on JBTM-2432: ---------------------------------------- Not yet but but forum thread https://developer.jboss.org/thread/260122 makes the decision to allow Java 8 for feature development whilst keeping with Java 7 for bug fixes. I have changed the CI job to compile and run our surefire tests on the Java 7 ibm and skip any tests that require a wildfly container. > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 09:30:03 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 12 Jun 2015 09:30:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078208#comment-13078208 ] Mark Little commented on JBTM-2432: ----------------------------------- That's WildFly and I do understand why they're moving to 8. However, if someone wants to build a component project using 7 then why wouldn't we allow that within that project until/unless we add features only available in 8? > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 09:57:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Jun 2015 09:57:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078225#comment-13078225 ] Michael Musgrove commented on JBTM-2432: ---------------------------------------- Yes that is what I have done - the only thing I disabled are the tests that require a WildFly container:- if we build on Java 7 and then run arquillian tests using an Arquillian WildFly Managed Container Adapter that connects to a WildFly that was built using Java 8 then we get errors because Arquillian says "it cannot start container". The CI job that tests we build and run on IBMs J9 Java7 JVM (that's a mouthful) should continue to pass. However if, in the future, a developer were to use a Java 8 feature then this CI job will start failing (unless IBM decide to support their J9 Java 8 compiler on linux). > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 12 10:02:09 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 12 Jun 2015 10:02:09 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078225#comment-13078225 ] Michael Musgrove edited comment on JBTM-2432 at 6/12/15 10:02 AM: ------------------------------------------------------------------ Yes that is what I have done - the only thing I disabled in the particular CI job are the tests that require a WildFly container:- if we build on Java 7 and then run arquillian tests using an Arquillian WildFly Managed Container Adapter that connects to a WildFly that was built using Java 8 then we get errors because Arquillian says "it cannot start container". The CI job that tests we build and run on IBMs J9 Java7 JVM (that's a mouthful) should continue to pass. However if, in the future, a developer were to use a Java 8 feature then this CI job will start failing (unless IBM decide to support their J9 Java 8 compiler on linux). was (Author: mmusgrov): Yes that is what I have done - the only thing I disabled are the tests that require a WildFly container:- if we build on Java 7 and then run arquillian tests using an Arquillian WildFly Managed Container Adapter that connects to a WildFly that was built using Java 8 then we get errors because Arquillian says "it cannot start container". The CI job that tests we build and run on IBMs J9 Java7 JVM (that's a mouthful) should continue to pass. However if, in the future, a developer were to use a Java 8 feature then this CI job will start failing (unless IBM decide to support their J9 Java 8 compiler on linux). > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.later > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:28:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 06:28:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2430: -------------------------------------- Assignee: Michael Musgrove (was: Tomasz Adamski) > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:51:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 06:51:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2430: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/868 > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:52:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 06:52:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2432. ------------------------------------ Fix Version/s: 5.next (was: 5.later) Resolution: Done > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 06:58:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 06:58:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078940#comment-13078940 ] Michael Musgrove commented on JBTM-2432: ---------------------------------------- Note that I have resolved the issue without a PR since the fix was to the CI job config (as per my previous comment on this JIRA) > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 07:01:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 07:01:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1359) HA Recovery Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1359: ----------------------------------- Priority: Optional (was: Major) > HA Recovery Manager > ------------------- > > Key: JBTM-1359 > URL: https://issues.jboss.org/browse/JBTM-1359 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, JTS, Recovery, XTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.later > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > JTA should work, but must consider JTS and XTS too (encoded IP addresses in log records) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 07:07:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 07:07:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1359) HA Recovery Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1359: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/668 > HA Recovery Manager > ------------------- > > Key: JBTM-1359 > URL: https://issues.jboss.org/browse/JBTM-1359 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, JTS, Recovery, XTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.later > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > JTA should work, but must consider JTS and XTS too (encoded IP addresses in log records) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 07:08:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 07:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1359) HA Recovery Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078954#comment-13078954 ] Michael Musgrove commented on JBTM-1359: ---------------------------------------- I have a fix for this (see PR) but I have dropped the priority to optional since the original requirement (PRODMGT-405) was rejected. > HA Recovery Manager > ------------------- > > Key: JBTM-1359 > URL: https://issues.jboss.org/browse/JBTM-1359 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, JTS, Recovery, XTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.later > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > JTA should work, but must consider JTS and XTS too (encoded IP addresses in log records) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 07:18:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 07:18:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2425: ------------------------------------ Needs an upgrade to 10.0.0.Alpha4-SNAPSHOT > Upgrade to latest wildfly version > --------------------------------- > > Key: JBTM-2425 > URL: https://issues.jboss.org/browse/JBTM-2425 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 08:21:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 08:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2425: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/869 (was: https://github.com/jbosstm/narayana/pull/857) > Upgrade to latest wildfly version > --------------------------------- > > Key: JBTM-2425 > URL: https://issues.jboss.org/browse/JBTM-2425 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 08:22:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 08:22:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2425) Upgrade to latest wildfly version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2425. ------------------------------------ Resolution: Done > Upgrade to latest wildfly version > --------------------------------- > > Key: JBTM-2425 > URL: https://issues.jboss.org/browse/JBTM-2425 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Latest is 10.0.0.Alpha3-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 15 13:29:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jun 2015 13:29:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2398: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/870 I have sub-typed VolatileStore and TwoPhaseVolatileStore since adding lookup by type name support has a performance impact: - I need to maintain a mapping from uid -> typeName - I update the mapping on each write_committed call The new store types are TypedVolatileStore and TypedTwoPhaseVolatileStore. > Support VolatileStore.allObjUids > --------------------------------- > > Key: JBTM-2398 > URL: https://issues.jboss.org/browse/JBTM-2398 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Performance Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.later > > > This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 06:44:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Jun 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2433) TransactionRolledBackException in MultiCloseTest In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2433: ------------------------------------- Summary: TransactionRolledBackException in MultiCloseTest Key: JBTM-2433 URL: https://issues.jboss.org/browse/JBTM-2433 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.later Attachments: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/858/PROFILE=XTS,jdk=jdk8.latest,label=linux {code} ------------------------------------------------------------------------------- Test set: com.arjuna.wstx.tests.arq.ba.MultiCloseTest ------------------------------------------------------------------------------- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.117 sec <<< FAILURE! testMultiClose(com.arjuna.wstx.tests.arq.ba.MultiCloseTest) Time elapsed: 2.5 sec <<< ERROR! com.arjuna.wst.TransactionRolledBackException: null at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) at com.arjuna.wstx.tests.arq.ba.MultiCloseTest.testMultiClose(MultiCloseTest.java:71) {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 06:44:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 16 Jun 2015 06:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2433) TransactionRolledBackException in MultiCloseTest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2433: ---------------------------------- Attachment: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt > TransactionRolledBackException in MultiCloseTest > ------------------------------------------------ > > Key: JBTM-2433 > URL: https://issues.jboss.org/browse/JBTM-2433 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.later > > Attachments: com.arjuna.wstx.tests.arq.ba.MultiCloseTest-output.txt > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/858/PROFILE=XTS,jdk=jdk8.latest,label=linux > {code} > ------------------------------------------------------------------------------- > Test set: com.arjuna.wstx.tests.arq.ba.MultiCloseTest > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.117 sec <<< FAILURE! > testMultiClose(com.arjuna.wstx.tests.arq.ba.MultiCloseTest) Time elapsed: 2.5 sec <<< ERROR! > com.arjuna.wst.TransactionRolledBackException: null > at com.arjuna.wst11.stub.BusinessActivityTerminatorStub.close(BusinessActivityTerminatorStub.java:95) > at com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple.close(UserBusinessActivityImple.java:157) > at com.arjuna.wstx.tests.arq.ba.MultiCloseTest.testMultiClose(MultiCloseTest.java:71) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 16 07:08:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 16 Jun 2015 07:08:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2432) Cannot test IBM J9 VM on linux In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079609#comment-13079609 ] Tom Jenkinson commented on JBTM-2432: ------------------------------------- I think what is happening is (I agree confusing) but you are using download director to download the package. Download director needs the Java plugin installing and Chrome (which you are using) doesn't like plugins anymore so the page doesn't think its installed and redirects you to Oracle to update your version of Java so you can then use the download manager (as I say, confusing and unclear) Two options: 1. Use a different browser to download it 2. There is an option to switch to direct download a. http://www.ibm.com/developerworks/java/jdk/linux/download.html b. click "Java SE Version 8 (last updated: 01 May 2015)" c. choose "64-bit AMD/Opteron/EM64T" d. "Download Now" e. enter data f. Toggle table to "Download using http" <--- THIS IS THE KEY BIT > Cannot test IBM J9 VM on linux > ------------------------------- > > Key: JBTM-2432 > URL: https://issues.jboss.org/browse/JBTM-2432 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > > We currently have provisional support for the IBM? J9 virtual machine for Java 7 but building narayana master now requires Java 8 (which we inherited from WildFly master which enforces Java 8). > Now it appears that the J9 virtual machine for Java 8 is not available on linux. When you go to the download page the linux download button redirects to the Oracle Hot Spot VM. We either need to abandon support for J9 or we add a CI machine running z/OS -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 06:25:03 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Jun 2015 06:25:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2434) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris moved WFLY-4784 to JBTM-2434: --------------------------------------------- Project: JBoss Transaction Manager (was: WildFly) Key: JBTM-2434 (was: WFLY-4784) Affects Version/s: (was: 8.2.0.Final) (was: 9.0.0.CR1) Component/s: JTA (was: CDI / Weld) (was: Transactions) > @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2434 > URL: https://issues.jboss.org/browse/JBTM-2434 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Environment: JDK 1.7u72 x64, Windows 8.1 Professional > Reporter: Alexander Morozov > Assignee: Gytis Trikleris > Priority: Critical > Attachments: wildfly-jta-cdi.zip > > > It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that > {code} > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ......... > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 06:26:22 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Jun 2015 06:26:22 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2434) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080149#comment-13080149 ] Gytis Trikleris commented on JBTM-2434: --------------------------------------- Moved to JBTM because the fix will go into Narayana and then will be added to WildFly once next Narayana is released. > @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2434 > URL: https://issues.jboss.org/browse/JBTM-2434 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Environment: JDK 1.7u72 x64, Windows 8.1 Professional > Reporter: Alexander Morozov > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 5.next > > Attachments: wildfly-jta-cdi.zip > > > It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that > {code} > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ......... > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 06:26:22 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Jun 2015 06:26:22 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2434) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2434: ---------------------------------- Fix Version/s: 5.next > @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2434 > URL: https://issues.jboss.org/browse/JBTM-2434 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Environment: JDK 1.7u72 x64, Windows 8.1 Professional > Reporter: Alexander Morozov > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 5.next > > Attachments: wildfly-jta-cdi.zip > > > It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that > {code} > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ......... > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 06:33:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Jun 2015 06:33:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2434) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2434: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/872 > @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2434 > URL: https://issues.jboss.org/browse/JBTM-2434 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Environment: JDK 1.7u72 x64, Windows 8.1 Professional > Reporter: Alexander Morozov > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 5.next > > Attachments: wildfly-jta-cdi.zip > > > It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that > {code} > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ......... > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 07:06:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Jun 2015 07:06:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2430: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 08:20:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Jun 2015 08:20:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2308: ------------------------------------ Failed on windows > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0, 5.next > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 08:21:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Jun 2015 08:21:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2308: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/795, https://github.com/jbosstm/narayana/pull/796, https://github.com/jbosstm/narayana/pull/865, https://github.com/jbosstm/narayana/pull/871 (was: https://github.com/jbosstm/narayana/pull/795, https://github.com/jbosstm/narayana/pull/796, https://github.com/jbosstm/narayana/pull/865) > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.27, 5.1.0, 5.next > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 08:48:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 17 Jun 2015 08:48:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2434) @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2434: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > @Transactional annotation on stereotype leads to error "ARJUNA016107: Expected an @Transactional annotation at class and/or method level" > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2434 > URL: https://issues.jboss.org/browse/JBTM-2434 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Environment: JDK 1.7u72 x64, Windows 8.1 Professional > Reporter: Alexander Morozov > Assignee: Gytis Trikleris > Priority: Critical > Fix For: 5.next > > Attachments: wildfly-jta-cdi.zip > > > It is seems that CDI Transactional extesion doesn't support well @Transactional annotation on CDI stereotypes. JTA transaction is created by library interceptor, but in case of exception on component's side, _com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(...)_ method failed to locate @Transactional annotation on target component. It leads to exception like that > {code} > java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:83) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:118) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx(TransactionalInterceptorBase.java:106) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorMandatory.intercept(TransactionalInterceptorMandatory.java:58) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldSubclass.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserEventDispatcher$Proxy$_$$_WeldClientProxy.dispatch(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService.addUser(UserApplicationService.java:18) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser$$super(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) > at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) > at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) > at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) > at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldSubclass.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.UserApplicationService$Proxy$_$$_WeldClientProxy.addUser(Unknown Source) > at com.mycompany.wildfly.jta.cdi.BootstrapExtension.start(BootstrapExtension.java:20) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ......... > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 10:02:06 2015 From: issues at jboss.org (=?UTF-8?Q?Vlastimil_Eli=C3=A1=C5=A1_=28JIRA=29?=) Date: Wed, 17 Jun 2015 10:02:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vlastimil Eli?? moved ORG-1631 to JBTM-2435: -------------------------------------------- Project: JBoss Transaction Manager (was: jboss.org) Key: JBTM-2435 (was: ORG-1631) Workflow: GIT Pull Request workflow (was: JBoss Community Team workflow) > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 10:44:02 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 17 Jun 2015 10:44:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080389#comment-13080389 ] Tomasz Adamski commented on JBTM-2428: -------------------------------------- In the attached link in TestBaseOneServer#presetClientOrb you have following config: System.setProperty("org.omg.CORBA.ORBSingletonClass", "org.jacorb.orb.ORBSingleton"); System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB"); Has it been changed in your test? > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Tomasz Adamski > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 10:45:04 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Wed, 17 Jun 2015 10:45:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080389#comment-13080389 ] Tomasz Adamski edited comment on JBTM-2428 at 6/17/15 10:44 AM: ---------------------------------------------------------------- In the attached link in TestBaseOneServer#presetClientOrb you have following config: System.setProperty("org.omg.CORBA.ORBSingletonClass", "org.jacorb.orb.ORBSingleton"); System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB"); This can be a problem itself and tbh I believe it shouldn't even work. Have you changed it before running test? was (Author: tomekadamski): In the attached link in TestBaseOneServer#presetClientOrb you have following config: System.setProperty("org.omg.CORBA.ORBSingletonClass", "org.jacorb.orb.ORBSingleton"); System.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB"); Has it been changed in your test? > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Tomasz Adamski > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 10:55:03 2015 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Wed, 17 Jun 2015 10:55:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080399#comment-13080399 ] Ond?ej Chaloupka commented on JBTM-2428: ---------------------------------------- yes, I forgot to mention it. As this settings was working with jacorb it's still in our repo. But for my testing I've been experimenting with removing those values and changing it to some possible jdk orb alternatives. But to be honest I don't what could be the correct settings. > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Tomasz Adamski > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 17 16:13:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 17 Jun 2015 16:13:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080684#comment-13080684 ] Michael Musgrove commented on JBTM-2398: ---------------------------------------- I ran a benchmark using the two new stores and there is a big difference (300%) when running a workload using multiple threads and there is a 30% difference with one thread. These differences warrant introducing new subclasses. The 3 fold difference with the TypedVolatileStore test makes no sense but is definitely consistent: -i 1 -wi 10 -f 1 -t 10 -r 100 # 10 warm up iterations and then a single iteration lasting 100 seconds using 10 threads c.a.a.j.x.p.VolatileStoreBenchmark.testVolatileStore thrpt 1 639773.579 NaN ops/s c.a.a.j.x.p.TypedVolatileStoreBenchmark.testVolatileStore thrpt 1 183711.939 NaN ops/s c.a.a.j.x.p.TwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 151985.542 NaN ops/s c.a.a.j.x.p.TypedTwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 103152.792 NaN ops/s -i 1 -wi 10 -f 1 -t 1 -r 100 # 10 warm up iterations and then a single iteration lasting 100 seconds using 1 thread c.a.a.j.x.p.VolatileStoreBenchmark.testVolatileStore thrpt 1 191072.127 NaN ops/s c.a.a.j.x.p.TypedVolatileStoreBenchmark.testVolatileStore thrpt 1 142127.089 NaN ops/s c.a.a.j.x.p.TwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 137941.989 NaN ops/s c.a.a.j.x.p.TypedTwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 114109.209 NaN ops/s > Support VolatileStore.allObjUids > --------------------------------- > > Key: JBTM-2398 > URL: https://issues.jboss.org/browse/JBTM-2398 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Performance Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.later > > > This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 04:39:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 04:39:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080856#comment-13080856 ] Tom Jenkinson commented on JBTM-2435: ------------------------------------- Thanks for the report but it depends on whether IE8 can be added to the upstream pressgang project. I know it renders fine on IE11 as that is what I have here. If you have a fix, please do consider signing our CLA and raising a PR over here: https://github.com/jbosstm/documentation otherwise I recommend you to try to get a change fixed in the upstream page generation tool. > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 04:39:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 04:39:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2435. ------------------------------- Resolution: Migrated to another ITS > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 04:49:03 2015 From: issues at jboss.org (Jaromir Hamala (JIRA)) Date: Thu, 18 Jun 2015 04:49:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080872#comment-13080872 ] Jaromir Hamala commented on JBTM-2435: -------------------------------------- Hello Tom, Thank you for looking into this. I don't really have IE to my disposal at this moment. When I was reporting this issue 2 years ago I was doing on-site consultancy gig for a customer where IE8 was the allowed browser allowed :-( Sadly it wasn't that uncommon rule for some organizations back then. I though you'd like to know your documentation wasn't usable in these environments. Hopefully silly rules regarding browsers are less common by now or at least the favour newer & more sane browsers now:)) Cheers, Jaromir > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 04:55:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 04:55:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2435: -------------------------------- Thanks Jaromir - it just landed on my desk now (I think it had been in a different Jira project), sorry for the delay in responding! > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 04:57:07 2015 From: issues at jboss.org (Jaromir Hamala (JIRA)) Date: Thu, 18 Jun 2015 04:57:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2435) Generated documentation doesn't render in Internet Explorer 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080885#comment-13080885 ] Jaromir Hamala commented on JBTM-2435: -------------------------------------- no worries. I managed to get the informations I wanted anyway. Kudos for really good content of you documentation! > Generated documentation doesn't render in Internet Explorer 8 > -------------------------------------------------------------- > > Key: JBTM-2435 > URL: https://issues.jboss.org/browse/JBTM-2435 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Environment: WinXP, Internet Exporer 8 > Reporter: Jaromir Hamala > Attachments: jboss_docs_ie_bug.png > > > Hi, > I noticed documentation at docs.jboss.org doesn't render properly in IE8. > How to reproduce it: > Open this URL in IE8: http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/ > Expected behaviour: > Documentation should be rendered > Current behavour: > Document is not rendered > I noticed it's affecting multiple pages, not just this one. Therefore I assume there is a bug in a DocBook template. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 05:17:05 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Thu, 18 Jun 2015 05:17:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080901#comment-13080901 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- Hi Tom, There is currently some ongoing discussion between one of our customers and JBoss Support regarding this behavior: I was under the impression, based on your statement from March, 3rd 2014, that this was fixed for XA_RB* as well as XA_RMFAIL, could you please clarify? Our position is, that it is a bug to not return an exception to the client, if the resource manager returns XA_RMFAIL to an 1-phase commit invocation. (I'll search for the respective statements in the EJB 3.0 spec that mandate/imply this later, in case that you have a different position.) Of course it can't return an EJBTransactionRolledbackException in this particular case, as the transaction status is unknown, but a generic EJBTransaction containing the message, that the transaction outcome is unclear would be just fine. In this case user interaction is required anyways, because JBoss recovery could never handle such a transaction, because it has never reached the "Prepare" state. Best regards, Christian > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 08:03:05 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Thu, 18 Jun 2015 08:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081010#comment-13081010 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- Hi Tom, A small update from our tests (JTA, a single resource only): Actually, if we provoke XA_RB* or XA_RMFAIL in end(), the bean caller *will* receive an EJBTransactionRolledbackException. (so you're correct, that it is fixed for both) If we let end() succeed and provoke XA_RB* or XA_RMFAIL in commit(), then the bean will receive an EJBTransactionRolledbackException if it was XA_RB*, but the error is swallowed if XA_RMFAIL is thrown (expected: EJBException). The argument why this is wrong is the same as for end() -- I'll reopen the issue, because it's conceptually the same error as with end() (and I think the JTS fix was also tracked under this here) Best regards, Christian > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 08:03:05 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Thu, 18 Jun 2015 08:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian von Kutzleben reopened JBTM-1702: ------------------------------------------- see comment > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 08:25:03 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Thu, 18 Jun 2015 08:25:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081011#comment-13081011 ] Christian von Kutzleben edited comment on JBTM-1702 at 6/18/15 8:24 AM: ------------------------------------------------------------------------ - was (Author: cvk): see comment > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 09:54:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 18 Jun 2015 09:54:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2370) Document how to run the performance benchmark standalone and link this from performance runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2370. ------------------------------------ Fix Version/s: 5.next (was: 5.later) Resolution: Done Commit c9c5944 adds text to the PR job output linking to the required README.md file (https://github.com/jbosstm/performance/tree/master/narayana) (see commit 90eae81 in the performance repo). > Document how to run the performance benchmark standalone and link this from performance runs > -------------------------------------------------------------------------------------------- > > Key: JBTM-2370 > URL: https://issues.jboss.org/browse/JBTM-2370 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.next > > > Create an article on our wiki (or maybe better done by updating the https://github.com/jbosstm/performance/blob/master/README.md) and then link it from the performance output. > It doesn't need to say how to run against the PR I would say, that can be left to the reader. > Nothing too heavy, just the general flags and how to run it. > git clone narayana master > git clone performance master > (cd narayana && ./build.sh -DskipTests) > (cd performance && ./build.sh -DskipTests) > cd performance > export JMH_ARGS=... > ./build.sh... -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 12:09:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 12:09:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081212#comment-13081212 ] Tom Jenkinson commented on JBTM-1702: ------------------------------------- Hi Christian, we discussed this quite a while ago now. Please can you confirm with a small JTATest what you are saying does not work? As a "starter for 10" I have attached a small (none-JTS) example that shows you get a rollbackexception if xa_end returns RMFAIL. Please amend the test to the error codes you want and share back. BTW - It will be best for you to create a discussion on the forum rather than try to discuss it in the comments of this Jira until we get to the bottom of it. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 12:10:05 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 12:10:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1702: -------------------------------- Attachment: JTATest.java > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 18 12:24:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jun 2015 12:24:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081223#comment-13081223 ] Tom Jenkinson commented on JBTM-1702: ------------------------------------- Also, for RMFAIL with JTS the OTS specification comes into play here and it means that we are unable to return the RolledbackException. If you look in OTS TRANS 1.4 you can see the interface for org.omg.CosTransactions.ResourceOperations::commit_one_phase() throws org.omg.CosTransactions.HeuristicHazard which means that the xa_end we do because the resource has not been delisted manually results in a CORBA UNKNOWN which the parent coordinator has to interpret as ambiguous and to be resolved by the recovery system. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 03:56:04 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Fri, 19 Jun 2015 03:56:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081415#comment-13081415 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- Hi Tom, please see my second post from yesterday: we created a test case, that provokes RMFAIL or RB* in xa_end or xa_commit: As you say, it's not a problem with xa_end: RMFAIL and RB* both result in a EJBTransactionRolledbackException (with EAP 6.2.4) What our customer encountered is a slight variation: the xa_end did not raise an exception, but the subsequent xa_commit (1phase opt) did, and here the exception gets swallowed if it was an RMFAIL. Of course that transaction outcome is unknown and has to be handled by the user. It can't be handled by JBoss recovery (because the transaction is not prepared, it can't be reported to the JBoss recovery system). If the transaction was not committed, it will be handled by the recovery system of the resource (here: our database server). What we expect is an EJBException (not EJBTransactionRolledbackException) that signals the user, that something went wrong and the transaction outcome in unclear. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 09:18:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 09:18:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081584#comment-13081584 ] Tom Jenkinson commented on JBTM-1702: ------------------------------------- Please can you create a forum topic to discuss this? It's best to discuss on there so that the community can all contribute. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 09:34:03 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Fri, 19 Jun 2015 09:34:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081605#comment-13081605 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- Sorry, I won't discuss that in the forum for reasons. Also our position is, that this is clearly described, undeniable bug in the contract between bean container and bean user (not between container and XAResource). If you don't fix that, I would appreciate if you let our customer know, how he should handle the situation. The only way I see right now is to enforce 2-phase-commit by enlisting a dummy XAResource in the bean. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:05:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 10:05:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081637#comment-13081637 ] Tom Jenkinson commented on JBTM-1702: ------------------------------------- Its difficult to work out if there is a bug or not based on the interaction so far. It is definitely best to discuss this over here: https://developer.jboss.org/en/jbosstm/ so we can better help you and our community. The forum is much better for discussion of whether something is an issue, once we have a clear picture then we can either raise an issue here in Jira or help to identify suitable changes elsewhere as appropriate. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:05:04 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 19 Jun 2015 10:05:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081638#comment-13081638 ] Mark Little commented on JBTM-1702: ----------------------------------- JIRA is not a discussion forum. I fail to see why these conversations could not be taken to a forum, especially given that this entire thread is publicly viewable anyway! > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:16:04 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Fri, 19 Jun 2015 10:16:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081651#comment-13081651 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- Mike, you're right. But this is not a discussion but a bug report. Tom, I appreciate discussing this with you, but all has been said in this thread. Two times. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:16:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 10:16:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1702. ------------------------------- Resolution: Done > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 5.0.2, 4.17.18 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:19:03 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Fri, 19 Jun 2015 10:19:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081652#comment-13081652 ] Mark Little commented on JBTM-1702: ----------------------------------- Mike? Who is Mike? ;) Anyway, this sounds like a Monty Python sketch (https://www.youtube.com/watch?v=kQFKtI6gn9Y). It's a discussion (http://dictionary.reference.com/browse/discuss). Please take it elsewhere as Tom has requested. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:35:20 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 10:35:20 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-1702: --------------------------------- Reopening to add forum link > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:35:21 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 10:35:21 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1702: -------------------------------- Forum Reference: https://developer.jboss.org/message/934165#934165 > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 19 10:35:22 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 19 Jun 2015 10:35:22 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1702. ------------------------------- Resolution: Done Linked to forum discussion added https://developer.jboss.org/message/934165#934165 > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 5.0.2, 4.17.18 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 05:34:02 2015 From: issues at jboss.org (Mark Little (JIRA)) Date: Mon, 22 Jun 2015 05:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2267) Create a docker image with JTS transaction manager and recovery manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082058#comment-13082058 ] Mark Little commented on JBTM-2267: ----------------------------------- Better to take this discussion to the forums rather than on a closed JIRA. > Create a docker image with JTS transaction manager and recovery manager > ----------------------------------------------------------------------- > > Key: JBTM-2267 > URL: https://issues.jboss.org/browse/JBTM-2267 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Mark Little > Attachments: Screen Shot 2014-11-23 at 18.35.40.png > > > Should help with a) using docker and b) providing transactions-as-a-service. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 10:57:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 22 Jun 2015 10:57:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2436) Use ManagedThreadFactory, if available, to create PeriodicRecovery thread In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2436: ------------------------------------- Summary: Use ManagedThreadFactory, if available, to create PeriodicRecovery thread Key: JBTM-2436 URL: https://issues.jboss.org/browse/JBTM-2436 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transaction Core Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 10:57:02 2015 From: issues at jboss.org (Jive JIRA Integration (JIRA)) Date: Mon, 22 Jun 2015 10:57:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2436) Use ManagedThreadFactory, if available, to create PeriodicRecovery thread In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jive JIRA Integration updated JBTM-2436: ---------------------------------------- Forum Reference: https://developer.jboss.org/message/934295#934295 > Use ManagedThreadFactory, if available, to create PeriodicRecovery thread > ------------------------------------------------------------------------- > > Key: JBTM-2436 > URL: https://issues.jboss.org/browse/JBTM-2436 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 22 14:15:06 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 22 Jun 2015 14:15:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082318#comment-13082318 ] Michael Musgrove commented on JBTM-2398: ---------------------------------------- After the code review I have moved the implementation of the new methods into VolatileStore and TwoPhaseVolatileStore and added a new property to the store configuration bean to control the behaviour. As expected the change has no effect on the benchmarks for the new stores: -i 1 -wi 10 -f 1 -t 10 -r 100 # 10 warm up iterations and then a single iteration lasting 100 seconds using 1 thread c.a.a.j.x.p.VolatileStoreBenchmark.testVolatileStore thrpt 1 637563.988 NaN ops/s c.a.a.j.x.p.TypedVolatileStoreBenchmark.testVolatileStore thrpt 1 185962.192 NaN ops/s c.a.a.j.x.p.TwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 144480.394 NaN ops/s c.a.a.j.x.p.TypedTwoPhaseVolatileStoreBenchmark.testVolatileStore thrpt 1 107737.372 NaN ops/s > Support VolatileStore.allObjUids > --------------------------------- > > Key: JBTM-2398 > URL: https://issues.jboss.org/browse/JBTM-2398 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Performance Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.later > > > This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:19:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:19:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2437: ------------------------------------- Summary: Failed to deploy BlackTie administration service Key: JBTM-2437 URL: https://issues.jboss.org/browse/JBTM-2437 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Priority: Minor Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 {code} Running AdvertiseUnadvertiseTest 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:24:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:24:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2438) jtax tests failed to find transaction records In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2438: ------------------------------------- Summary: jtax tests failed to find transaction records Key: JBTM-2438 URL: https://issues.jboss.org/browse/JBTM-2438 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Reporter: Gytis Trikleris Assignee: Tom Jenkinson Priority: Minor Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/940 {code} Running com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.359 sec <<< FAILURE! heuristicInformationTest(com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest) Time elapsed: 0.687 sec <<< ERROR! javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe00_55840df4_0 at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) at com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest.heuristicInformationTest(HeuristicInformationTest.java:106) Running com.hp.mwtests.ts.jta.jts.tools.JTSOSBTransactionTypeTests Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.188 sec Running com.hp.mwtests.ts.jta.jts.tools.JTSObjStoreBrowserTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec Running com.hp.mwtests.ts.jta.jts.tools.JTSXARTest Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.969 sec <<< FAILURE! testXAR(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 1.015 sec <<< ERROR! javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_2 at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testXAR(JTSXARTest.java:113) testHeuristic(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 0.25 sec <<< ERROR! javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_15 at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testHeuristic(JTSXARTest.java:118) {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:26:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2438) jtax tests failed to find transaction records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082562#comment-13082562 ] Gytis Trikleris commented on JBTM-2438: --------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/939/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/938/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/937/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/936/ > jtax tests failed to find transaction records > --------------------------------------------- > > Key: JBTM-2438 > URL: https://issues.jboss.org/browse/JBTM-2438 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/940 > {code} > Running com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.359 sec <<< FAILURE! > heuristicInformationTest(com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest) Time elapsed: 0.687 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe00_55840df4_0 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest.heuristicInformationTest(HeuristicInformationTest.java:106) > Running com.hp.mwtests.ts.jta.jts.tools.JTSOSBTransactionTypeTests > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.188 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSObjStoreBrowserTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSXARTest > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.969 sec <<< FAILURE! > testXAR(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 1.015 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_2 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testXAR(JTSXARTest.java:113) > testHeuristic(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 0.25 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_15 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testHeuristic(JTSXARTest.java:118) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:26:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2438) jtax tests failed to find transaction records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2438: ---------------------------------- Priority: Critical (was: Minor) > jtax tests failed to find transaction records > --------------------------------------------- > > Key: JBTM-2438 > URL: https://issues.jboss.org/browse/JBTM-2438 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/940 > {code} > Running com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.359 sec <<< FAILURE! > heuristicInformationTest(com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest) Time elapsed: 0.687 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe00_55840df4_0 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest.heuristicInformationTest(HeuristicInformationTest.java:106) > Running com.hp.mwtests.ts.jta.jts.tools.JTSOSBTransactionTypeTests > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.188 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSObjStoreBrowserTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSXARTest > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.969 sec <<< FAILURE! > testXAR(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 1.015 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_2 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testXAR(JTSXARTest.java:113) > testHeuristic(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 0.25 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_15 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testHeuristic(JTSXARTest.java:118) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:29:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:29:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2438) jtax tests failed to find transaction records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082565#comment-13082565 ] Gytis Trikleris commented on JBTM-2438: --------------------------------------- This is a different test, but looks like the same issue: http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/934/ > jtax tests failed to find transaction records > --------------------------------------------- > > Key: JBTM-2438 > URL: https://issues.jboss.org/browse/JBTM-2438 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/940 > {code} > Running com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.359 sec <<< FAILURE! > heuristicInformationTest(com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest) Time elapsed: 0.687 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe00_55840df4_0 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest.heuristicInformationTest(HeuristicInformationTest.java:106) > Running com.hp.mwtests.ts.jta.jts.tools.JTSOSBTransactionTypeTests > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.188 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSObjStoreBrowserTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSXARTest > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.969 sec <<< FAILURE! > testXAR(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 1.015 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_2 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testXAR(JTSXARTest.java:113) > testHeuristic(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 0.25 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_15 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testHeuristic(JTSXARTest.java:118) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:32:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:32:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082567#comment-13082567 ] Gytis Trikleris commented on JBTM-2437: --------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/867/ > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:32:03 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:32:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2437: ---------------------------------- Priority: Major (was: Minor) > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:34:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082567#comment-13082567 ] Gytis Trikleris edited comment on JBTM-2437 at 6/23/15 5:33 AM: ---------------------------------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/867/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/866/ http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/865/ was (Author: gytis): http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/867/ > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:34:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2437: ---------------------------------- Priority: Critical (was: Major) > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Critical > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:36:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 23 Jun 2015 05:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2439) XATMI CSTest failed In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2439: ------------------------------------- Summary: XATMI CSTest failed Key: JBTM-2439 URL: https://issues.jboss.org/browse/JBTM-2439 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Gytis Trikleris Assignee: Amos Feng Priority: Minor Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/863 {code} Running org.jboss.narayana.blacktie.jatmibroker.xatmi.CSTest 20:00:30,081 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:00:30,372 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:00:30,597 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:00:41,182 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:00:41,531 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:00:41,788 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:00:44,655 ERROR [org.codehaus.stomp.tcp.TcpTransport] (StompConnect Transport: tcp:///127.0.0.1:55163) Caught an exception: null: java.lang.NullPointerException at org.codehaus.stomp.tcp.TcpTransport.run(TcpTransport.java:103) at java.lang.Thread.run(Thread.java:744) 20:00:54,478 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:00:54,749 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:00:55,057 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 123) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:01:05,617 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:01:05,865 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:01:06,103 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:01:16,623 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:01:16,900 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:01:17,169 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 125) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:01:38,604 WARN [org.jboss.narayana.blacktie.administration.QueueReaperBean] (EJB default - 1) undeploy service pending for .testsui1 as consumer count is 0, will check again in 30000ms 20:02:08,542 WARN [org.jboss.as.ejb3] (EJB default - 3) WFLYEJB0043: A previous execution of timer [id=ec057768-85a2-4e35-ac04-cebbf53ce28e timedObjectId=blacktie-admin-services-ear-5.1.2.Final-SNAPSHOT.blacktie-admin-services-5.1.2.Final-SNAPSHOT.QueueReaperBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 3aff5ed3 initialExpiration=Wed Jun 17 18:46:38 BST 2015 intervalDuration(in milli sec)=30000 nextExpiration=Wed Jun 17 20:02:08 BST 2015 timerState=IN_TIMEOUT info=queue reaper] is still in progress, skipping this overlapping scheduled execution at: Wed Jun 17 20:02:08 BST 2015. 20:02:08,781 WARN [org.jboss.narayana.blacktie.administration.QueueReaperBean] (EJB default - 1) undeploy service .testsui1 for consumer is 0 20:02:23,382 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:9d has 1 heuristic participant(s)! 20:02:23,382 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a42%3a173398/terminate 20:02:23,382 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:9d restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 5ec536b5 20:02:23,550 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:91 has 1 heuristic participant(s)! 20:02:23,551 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a35%3a424555/terminate 20:02:23,552 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:91 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 7642baf0 20:02:23,625 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:94 has 1 heuristic participant(s)! 20:02:23,626 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a36%3a409865/terminate 20:02:23,627 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:94 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 2ecad1c6 20:02:23,701 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a47%3a57%3a125401/terminate 20:02:23,743 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:a0 has 1 heuristic participant(s)! 20:02:23,744 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a43%3a212555/terminate 20:02:23,745 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:a0 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 2684d6dd 20:02:57,766 ERROR [org.jboss.narayana.blacktie.administration.core.AdministrationProxy] (Thread-36 (HornetQ-client-global-threads-1622216728)) call server testsui id 0 failed with 13: org.jboss.narayana.blacktie.jatmibroker.xatmi.ConnectionException: tperrno: 13 reason: Did not receive a message at org.jboss.narayana.blacktie.jatmibroker.core.transport.hybrid.SocketReceiverImpl.receive(SocketReceiverImpl.java:139) at org.jboss.narayana.blacktie.jatmibroker.xatmi.impl.ConnectionImpl.receive(ConnectionImpl.java:533) at org.jboss.narayana.blacktie.jatmibroker.xatmi.impl.ConnectionImpl.tpcall(ConnectionImpl.java:183) at org.jboss.narayana.blacktie.administration.core.AdministrationProxy.callAdminService(AdministrationProxy.java:75) at org.jboss.narayana.blacktie.administration.core.AdministrationProxy.shutdown(AdministrationProxy.java:350) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI.shutdown(BlacktieAdminServiceXATMI.java:346) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI.tpservice(BlacktieAdminServiceXATMI.java:132) at org.jboss.narayana.blacktie.jatmibroker.xatmi.BlackTieService.processMessage(BlackTieService.java:182) at org.jboss.narayana.blacktie.jatmibroker.xatmi.mdb.MDBBlacktieService.onMessage(MDBBlacktieService.java:66) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) at org.jboss.as.ejb3.tx.CMTTxInterceptor.never(CMTTxInterceptor.java:299) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:235) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:213) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:635) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI$$$view2.onMessage(Unknown Source) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139) at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI$$$endpoint2.onMessage(Unknown Source) at org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:321) at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1116) at org.hornetq.core.client.impl.ClientConsumerImpl.access$500(ClientConsumerImpl.java:56) at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1251) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) 20:02:57,814 ERROR [org.jboss.narayana.blacktie.jatmibroker.core.transport.hybrid.stomp.StompSenderImpl] (Thread-36 (HornetQ-client-global-threads-1622216728)) queue/BTR_.testsui1 -- service jboss.naming.context.java.queue."BTR_.testsui1" 20:02:57,815 ERROR [org.jboss.narayana.blacktie.administration.core.AdministrationProxy] (Thread-36 (HornetQ-client-global-threads-1622216728)) call server testsui id 0 failed with 6: org.jboss.narayana.blacktie.jatmibroker.xatmi.ConnectionException: tperrno: 6 reason: queue/BTR_.testsui1 -- service jboss.naming.context.java.queue."BTR_.testsui1" at org.jboss.narayana.blacktie.jatmibroker.core.transport.hybrid.stomp.StompSenderImpl.send(StompSenderImpl.java:144) at org.jboss.narayana.blacktie.jatmibroker.xatmi.impl.ConnectionImpl.tpacall(ConnectionImpl.java:260) at org.jboss.narayana.blacktie.jatmibroker.xatmi.impl.ConnectionImpl.tpcall(ConnectionImpl.java:181) at org.jboss.narayana.blacktie.administration.core.AdministrationProxy.callAdminService(AdministrationProxy.java:75) at org.jboss.narayana.blacktie.administration.core.AdministrationProxy.shutdown(AdministrationProxy.java:354) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI.shutdown(BlacktieAdminServiceXATMI.java:346) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI.tpservice(BlacktieAdminServiceXATMI.java:132) at org.jboss.narayana.blacktie.jatmibroker.xatmi.BlackTieService.processMessage(BlackTieService.java:182) at org.jboss.narayana.blacktie.jatmibroker.xatmi.mdb.MDBBlacktieService.onMessage(MDBBlacktieService.java:66) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) at org.jboss.as.ejb3.tx.CMTTxInterceptor.never(CMTTxInterceptor.java:299) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:235) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:213) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:635) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI$$$view2.onMessage(Unknown Source) at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139) at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) at org.jboss.narayana.blacktie.administration.BlacktieAdminServiceXATMI$$$endpoint2.onMessage(Unknown Source) at org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:321) at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1116) at org.hornetq.core.client.impl.ClientConsumerImpl.access$500(ClientConsumerImpl.java:56) at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1251) at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:104) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) 20:02:57,852 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 127) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:03:05,744 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:03:05,985 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:03:06,274 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:03:16,874 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:03:17,135 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:03:17,436 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:03:40,042 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:03:40,430 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:03:40,688 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:03:51,251 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:03:51,561 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:03:51,815 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:02,497 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:02,745 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:02,980 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 129) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:13,462 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 129) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:13,745 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 129) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:13,985 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 129) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:24,519 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:24,846 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:25,216 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:33,824 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:9d has 1 heuristic participant(s)! 20:04:33,825 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a42%3a42%3a173398/terminate 20:04:33,825 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:9d restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 32f599dc 20:04:33,910 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:91 has 1 heuristic participant(s)! 20:04:33,911 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a37%3a35%3a424555/terminate 20:04:33,911 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:91 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 4a493aa5 20:04:33,989 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:94 has 1 heuristic participant(s)! 20:04:33,990 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a39%3a36%3a409865/terminate 20:04:33,990 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:94 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 4afb2f0f 20:04:34,065 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a47%3a57%3a125401/terminate 20:04:34,098 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:a0 has 1 heuristic participant(s)! 20:04:34,099 INFO [org.jboss.jbossts.star.resource.RESTRecord] (Periodic Recovery) restore_state http://127.0.0.1:8888/xid/131077%3a102%3a0%3a44%3a43%3a212555/terminate 20:04:34,100 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a27a818:-3b8ac52f:5581b0d2:a0 restored heuristic participant org.jboss.jbossts.star.resource.RESTRecord at 2d1d86a 20:04:35,818 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:36,102 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:36,371 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:46,960 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:47,211 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:47,475 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall 20:04:58,025 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_.testsui1 20:04:58,376 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_BAR 20:04:58,624 INFO [org.hornetq.core.server] (ServerService Thread Pool -- 128) HQ221003: trying to deploy queue jms.queue.BTR_TestTPCall Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 279.072 sec <<< FAILURE! test_211(org.jboss.narayana.blacktie.jatmibroker.xatmi.CSTest) Time elapsed: 101.173 sec <<< FAILURE! junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:55) at junit.framework.Assert.assertTrue(Assert.java:22) at junit.framework.Assert.assertTrue(Assert.java:31) at junit.framework.TestCase.assertTrue(TestCase.java:201) at org.jboss.narayana.blacktie.jatmibroker.xatmi.CSControl.runTest(CSControl.java:153) at org.jboss.narayana.blacktie.jatmibroker.xatmi.CSTest.test_211(CSTest.java:27) {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:50:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 05:50:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2308. ------------------------------------ Resolution: Done > New JTS record types are not showing up in the tooling > ------------------------------------------------------ > > Key: JBTM-2308 > URL: https://issues.jboss.org/browse/JBTM-2308 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tooling > Affects Versions: 4.17.23, 5.0.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next, 5.1.0, 4.17.27 > > > When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record. > I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it). > What is missing is instrumentation for new types: > {code} > AssumedCompleteHeuristicTransaction > AssumedCompleteHeuristicServerTransaction > AssumedCompleteTransaction > AssumedCompleteServerTransaction > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 05:51:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 05:51:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2438) jtax tests failed to find transaction records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2438. ---------------------------------- Resolution: Duplicate Issue Duplicate of JBTM-2308 which I fixed after this run. > jtax tests failed to find transaction records > --------------------------------------------- > > Key: JBTM-2438 > URL: https://issues.jboss.org/browse/JBTM-2438 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/940 > {code} > Running com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.359 sec <<< FAILURE! > heuristicInformationTest(com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest) Time elapsed: 0.687 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe00_55840df4_0 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.HeuristicInformationTest.heuristicInformationTest(HeuristicInformationTest.java:106) > Running com.hp.mwtests.ts.jta.jts.tools.JTSOSBTransactionTypeTests > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.188 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSObjStoreBrowserTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec > Running com.hp.mwtests.ts.jta.jts.tools.JTSXARTest > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.969 sec <<< FAILURE! > testXAR(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 1.015 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_2 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testXAR(JTSXARTest.java:113) > testHeuristic(com.hp.mwtests.ts.jta.jts.tools.JTSXARTest) Time elapsed: 0.25 sec <<< ERROR! > javax.management.InstanceNotFoundException: jboss.jta:type=ObjectStore,itype=StateManager\BasicAction\TwoPhaseCoordinator\ArjunaTransactionImple,uid=0_ffff0a27a80e_fe09_55840dfc_15 > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) > at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643) > at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.validateChildBeans(JTSXARTest.java:125) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.injectCommitException(JTSXARTest.java:106) > at com.hp.mwtests.ts.jta.jts.tools.JTSXARTest.testHeuristic(JTSXARTest.java:118) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 06:04:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 06:04:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2440: -------------------------------------- Summary: Disable byteman tests when running with the IBM JVM Key: JBTM-2440 URL: https://issues.jboss.org/browse/JBTM-2440 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Affects Versions: 5.1.1 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: {code} *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 Exception in thread "Attachment 59984" Agent failed to start! JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 {code} I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 06:35:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 06:35:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/876 > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 06:36:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 06:36:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 06:46:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 06:46:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2401) Benchmark hang running product comparison tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2401. ---------------------------------- Resolution: Cannot Reproduce Bug Closing because I cannot reproduce it and it has low impact, ie just rerun the benchmark if it happens again. > Benchmark hang running product comparison tests > ----------------------------------------------- > > Key: JBTM-2401 > URL: https://issues.jboss.org/browse/JBTM-2401 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Attachments: 8857.jstack > > > The JMH benchmarking framework hung running io.narayana.perf.product.ProductComparison.testJotm during the following CI job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-benchmarks/12 > Please refer to the attached file for the jstack dump -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 07:05:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 07:05:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2440: ------------------------------------ We also need an ibm jdk profile in the ArjunaJTA jdbc module to disable another byteman test. > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 09:18:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 23 Jun 2015 09:18:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2437: -------------------------------- Priority: Blocker (was: Critical) > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 23 12:02:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 23 Jun 2015 12:02:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2441) Skip license download when building wildfly 5_BRANCH In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2441: -------------------------------------- Summary: Skip license download when building wildfly 5_BRANCH Key: JBTM-2441 URL: https://issues.jboss.org/browse/JBTM-2441 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Affects Versions: 5.1.1 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next A number of our CI jobs build the 5_BRANCH of wildfly (wildfly master + the narayana master) but they occasionally fail on the wildfly release profile whilst downloading the licenses (via the license-maven-plugin in feature-pack/pom.xml) running out of heap space. I will add -Dlicense.skipDownloadLicenses=true to our narayana.sh CI build script -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 04:07:03 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 24 Jun 2015 04:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083106#comment-13083106 ] Amos Feng commented on JBTM-2437: --------------------------------- It looks like the default resource adapter of the MDB changed from 'hornetq-ra' to 'activemq-ra' with https://github.com/wildfly/wildfly/blob/6ad049dd5f00967dcdff9ee75ec8aa918bf487fd/ejb3/src/main/resources/subsystem-templates/ejb3.xml#L54 > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 05:38:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 24 Jun 2015 05:38:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2437: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/877 > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 05:41:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 24 Jun 2015 05:41:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2442) Update to use activemq-messaging subsystem in the standalone-blacktie.xml In-Reply-To: References: Message-ID: Amos Feng created JBTM-2442: ------------------------------- Summary: Update to use activemq-messaging subsystem in the standalone-blacktie.xml Key: JBTM-2442 URL: https://issues.jboss.org/browse/JBTM-2442 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration, BlackTie Reporter: Amos Feng Assignee: Amos Feng Priority: Minor Fix For: 5.later currently the wildfly 10.0.0.Alpha4 changes to use the activemq-messaging and the default resource adapter of the MDB changed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 06:45:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 24 Jun 2015 06:45:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2441) Skip license download when building wildfly 5_BRANCH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2441. ------------------------------------ Resolution: Done > Skip license download when building wildfly 5_BRANCH > ---------------------------------------------------- > > Key: JBTM-2441 > URL: https://issues.jboss.org/browse/JBTM-2441 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > A number of our CI jobs build the 5_BRANCH of wildfly (wildfly master + the narayana master) but they occasionally fail on the wildfly release profile whilst downloading the licenses (via the license-maven-plugin in feature-pack/pom.xml) running out of heap space. > I will add -Dlicense.skipDownloadLicenses=true to our narayana.sh CI build script -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 07:33:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Jun 2015 07:33:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2442) Update to use activemq-messaging subsystem in the standalone-blacktie.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2442: -------------------------------- Priority: Major (was: Minor) > Update to use activemq-messaging subsystem in the standalone-blacktie.xml > ------------------------------------------------------------------------- > > Key: JBTM-2442 > URL: https://issues.jboss.org/browse/JBTM-2442 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.later > > > currently the wildfly 10.0.0.Alpha4 changes to use the activemq-messaging and the default resource adapter of the MDB changed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 11:59:04 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Jun 2015 11:59:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2443) Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2443: ----------------------------------- Summary: Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL Key: JBTM-2443 URL: https://issues.jboss.org/browse/JBTM-2443 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JTA, JTS Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next If a one phase commit is performed on an XAResource and it raises RMFAIL we have no way to know whether the resource committed or rolled back. We currently do not raise an exception in this scenario as an interpretation of the XA spec allows us to. We have had community feedback that this has an issue for user applications and having consulted with the rest of our community and no negative comments received we will modify the behavior so that this scenario results in the closest exception that JTA allows HeuristicMixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 11:59:05 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Jun 2015 11:59:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2443) Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2443: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/875 > Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL > ------------------------------------------------------------------------- > > Key: JBTM-2443 > URL: https://issues.jboss.org/browse/JBTM-2443 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > If a one phase commit is performed on an XAResource and it raises RMFAIL we have no way to know whether the resource committed or rolled back. We currently do not raise an exception in this scenario as an interpretation of the XA spec allows us to. > We have had community feedback that this has an issue for user applications and having consulted with the rest of our community and no negative comments received we will modify the behavior so that this scenario results in the closest exception that JTA allows HeuristicMixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 12:03:06 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 24 Jun 2015 12:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083419#comment-13083419 ] Tom Jenkinson commented on JBTM-1702: ------------------------------------- [~cvk] - you might be interested in https://issues.jboss.org/browse/JBTM-2443 - the reason it is separate to this issue is because RMFAIL is not equivalent to RB* error codes in the XA spec. It was categorised as feature request as it was a modification of behaviour that is compliant with XA, even if as you point out it restricted user applications. Note that RMFAIL does not mean the resource rolled back - we are throwing HeuristicMixed to indicate you cannot rely on the resources state as they may have commited before the connection broke for example. > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Jun 24 22:40:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 24 Jun 2015 22:40:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2437) Failed to deploy BlackTie administration service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2437: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Failed to deploy BlackTie administration service > ------------------------------------------------ > > Key: JBTM-2437 > URL: https://issues.jboss.org/browse/JBTM-2437 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana-catelyn/941 > {code} > Running AdvertiseUnadvertiseTest > 17:21:55,250 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location C:\hudson\workspace\narayana-catelyn\blacktie\wildfly-10.0.0.Alpha4-SNAPSHOT\standalone\data\content\01\b2548ae63569dec6b9fd46d34b21b7f7d0e55e\content > 17:21:55,297 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0027: Starting deployment of "test.war" (runtime-name: "test.war") > 17:21:56,047 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.test.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice. > 17:21:56,515 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0013: Deployment deployment "test.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > 17:21:56,797 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,797 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "test.war" was rolled back with the following failure message: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"test.war\".component.BlacktieStompAdministrationService.CREATE is missing [jboss.ra.activemq-ra]"]} > 17:21:56,843 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.1.3.Final > 17:21:57,094 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0028: Stopped deployment test.war (runtime-name: test.war) in 294ms > 17:21:57,094 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START (missing) dependents: [service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart, service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.VIEW."org.jboss.narayana.blacktie.administration.BlacktieStompAdministrationService".MESSAGE_ENDPOINT (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation] > service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".component."org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test, service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.deployment.unit."test.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START] > service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.START, service jboss.deployment.unit."test.war".moduleDeploymentRuntimeInformationStart] > service jboss.ra.activemq-ra (missing) dependents: [service jboss.deployment.unit."test.war".component.BlacktieStompAdministrationService.CREATE] > service jboss.undertow.deployment.default-server.default-host./test (missing) dependents: [service jboss.deployment.unit."test.war".deploymentCompleteService] > service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test] > service jboss.undertow.deployment.default-server.default-host./test.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService] > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.313 sec <<< FAILURE! > AdvertiseUnadvertiseTest Time elapsed: 6.313 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: test.war > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159) > at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 03:16:03 2015 From: issues at jboss.org (Christian von Kutzleben (JIRA)) Date: Thu, 25 Jun 2015 03:16:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083637#comment-13083637 ] Christian von Kutzleben commented on JBTM-1702: ----------------------------------------------- HeuristicMixed in this scenario sounds good! Thank you! > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > Attachments: JTATest.java > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1 at localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 09:43:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 09:43:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083804#comment-13083804 ] Tom Jenkinson commented on JBTM-2440: ------------------------------------- Do you know why these only seemed to start failing when we upgraded to JDK8? > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 09:43:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 09:43:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2443) Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2443: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Raise a JTA HeuristicMixed if a one phase commit XAResource raises RMFAIL > ------------------------------------------------------------------------- > > Key: JBTM-2443 > URL: https://issues.jboss.org/browse/JBTM-2443 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA, JTS > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > If a one phase commit is performed on an XAResource and it raises RMFAIL we have no way to know whether the resource committed or rolled back. We currently do not raise an exception in this scenario as an interpretation of the XA spec allows us to. > We have had community feedback that this has an issue for user applications and having consulted with the rest of our community and no negative comments received we will modify the behavior so that this scenario results in the closest exception that JTA allows HeuristicMixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 09:46:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 09:46:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2444) jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2444: ----------------------------------- Summary: jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ Key: JBTM-2444 URL: https://issues.jboss.org/browse/JBTM-2444 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Documentation Reporter: Tom Jenkinson Assignee: Gytis Trikleris Priority: Blocker Fix For: 5.next {code} Running org.jboss.narayana.quickstarts.jta.TestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.563 sec <<< FAILURE! Results : Tests in error: org.jboss.narayana.quickstarts.jta.TestCase: Cannot deploy: test.war Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 {code} The log file says: {code} Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /home/hudson/workspace/narayana-quickstarts/wildfly-10.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp/temp174d29cf17a7dbea/content-a7b7e754b2627502/WEB-INF/test-jms.xml Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[23,1] Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'"}} at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) ... 96 more {code} Which leads me to believe it is likely due to the parsing in test-jms.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 09:46:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 09:46:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2444) jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083806#comment-13083806 ] Tom Jenkinson commented on JBTM-2444: ------------------------------------- http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-quickstarts/221/ > jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ > --------------------------------------------------------------------------------------------- > > Key: JBTM-2444 > URL: https://issues.jboss.org/browse/JBTM-2444 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > {code} > Running org.jboss.narayana.quickstarts.jta.TestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.563 sec <<< FAILURE! > Results : > Tests in error: > org.jboss.narayana.quickstarts.jta.TestCase: Cannot deploy: test.war > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > {code} > The log file says: > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /home/hudson/workspace/narayana-quickstarts/wildfly-10.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp/temp174d29cf17a7dbea/content-a7b7e754b2627502/WEB-INF/test-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[23,1] > Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > ... 96 more > {code} > Which leads me to believe it is likely due to the parsing in test-jms.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 09:47:03 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 09:47:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2444) jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083808#comment-13083808 ] Tom Jenkinson commented on JBTM-2444: ------------------------------------- Consistently failing so it is a blocker for 5.2 - [~gytis], please can you have a look as a matter of urgency? > jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ > --------------------------------------------------------------------------------------------- > > Key: JBTM-2444 > URL: https://issues.jboss.org/browse/JBTM-2444 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > {code} > Running org.jboss.narayana.quickstarts.jta.TestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.563 sec <<< FAILURE! > Results : > Tests in error: > org.jboss.narayana.quickstarts.jta.TestCase: Cannot deploy: test.war > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > {code} > The log file says: > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /home/hudson/workspace/narayana-quickstarts/wildfly-10.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp/temp174d29cf17a7dbea/content-a7b7e754b2627502/WEB-INF/test-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[23,1] > Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > ... 96 more > {code} > Which leads me to believe it is likely due to the parsing in test-jms.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:03:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083821#comment-13083821 ] Michael Musgrove commented on JBTM-2440: ---------------------------------------- I not certain but diff'ing the config between now and the last successful build reveals that the tests were disabled NARAYANA_TESTS=0 on the sucessful build > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:15:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:15:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083829#comment-13083829 ] Michael Musgrove commented on JBTM-2440: ---------------------------------------- I do recall - we disable the tests because byteman is known not to work with the IBM J9 compiler. So the fix is just to go back to not running the tests on J9 and figure out how to make byteman work with J9 as an optional task. > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:15:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:15:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Priority: Optional (was: Major) > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:16:01 2015 From: issues at jboss.org (Tom Ross (JIRA)) Date: Thu, 25 Jun 2015 10:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2445) Back port JBTM-692 into EAP 5.2 In-Reply-To: References: Message-ID: Tom Ross created JBTM-2445: ------------------------------ Summary: Back port JBTM-692 into EAP 5.2 Key: JBTM-2445 URL: https://issues.jboss.org/browse/JBTM-2445 Project: JBoss Transaction Manager Issue Type: Support Patch Components: JTA, JTS Affects Versions: 4.6.1.CP13 Environment: JBoss EAP 5.2.0.GA Reporter: Tom Ross Assignee: Tom Ross Back port of JBTM-692 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:17:03 2015 From: issues at jboss.org (Tom Ross (JIRA)) Date: Thu, 25 Jun 2015 10:17:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2445) Back port JBTM-692 into EAP 5.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Ross deleted JBTM-2445: --------------------------- > Back port JBTM-692 into EAP 5.2 > ------------------------------- > > Key: JBTM-2445 > URL: https://issues.jboss.org/browse/JBTM-2445 > Project: JBoss Transaction Manager > Issue Type: Support Patch > Environment: JBoss EAP 5.2.0.GA > Reporter: Tom Ross > Assignee: Tom Ross > > Back port of JBTM-692 -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:21:02 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 25 Jun 2015 10:21:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2444) jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2444: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/142 > jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ > --------------------------------------------------------------------------------------------- > > Key: JBTM-2444 > URL: https://issues.jboss.org/browse/JBTM-2444 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > {code} > Running org.jboss.narayana.quickstarts.jta.TestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.563 sec <<< FAILURE! > Results : > Tests in error: > org.jboss.narayana.quickstarts.jta.TestCase: Cannot deploy: test.war > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > {code} > The log file says: > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /home/hudson/workspace/narayana-quickstarts/wildfly-10.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp/temp174d29cf17a7dbea/content-a7b7e754b2627502/WEB-INF/test-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[23,1] > Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > ... 96 more > {code} > Which leads me to believe it is likely due to the parsing in test-jms.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:50:05 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:50:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Disable byteman tests when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Priority: Blocker (was: Optional) > Disable byteman tests when running with the IBM JVM > --------------------------------------------------- > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:52:03 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:52:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Summary: Byteman tests fail when running with the IBM JVM (was: Disable byteman tests when running with the IBM JVM) > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 10:52:04 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 10:52:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Priority: Optional (was: Blocker) > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:57:08 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 11:57:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083938#comment-13083938 ] Michael Musgrove commented on JBTM-2440: ---------------------------------------- I am marking the jira as minor with the fix to add a new profile that disables all of the byteman tests. > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:57:08 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 11:57:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Priority: Minor (was: Optional) > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 11:58:05 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 25 Jun 2015 11:58:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083939#comment-13083939 ] Tom Jenkinson commented on JBTM-2440: ------------------------------------- Hi Mike, I think you should raise a BYTEMAN issue and link it to this one to see if Andrew can add support for J9. Tom > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Thu Jun 25 12:08:06 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 25 Jun 2015 12:08:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2440) Byteman tests fail when running with the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2440: ----------------------------------- Forum Reference: https://developer.jboss.org/message/934606#934606 > Byteman tests fail when running with the IBM JVM > ------------------------------------------------ > > Key: JBTM-2440 > URL: https://issues.jboss.org/browse/JBTM-2440 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Byteman instrumentation does not work with the IBM J9 JVM:- it fails with errors like the following: > {code} > *** java.lang.instrument ASSERTION FAILED ***: "jvmtierror == JVMTI_ERROR_NOT_AVAILABLE" at JPLISAgent.c line: 1009 > Exception in thread "Attachment 59984" Agent failed to start! > JVMJ9TI064E Agent initialization function Agent_OnAttach failed for library instrument, return code 102 > {code} > I will implement a workaround by disabling byteman when testing with this JVM. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 03:26:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 26 Jun 2015 03:26:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2446) Blacktie jatmibroker-xatmi hang with "javax.naming.NameNotFoundException: ConnectionFactory" In-Reply-To: References: Message-ID: Amos Feng created JBTM-2446: ------------------------------- Summary: Blacktie jatmibroker-xatmi hang with "javax.naming.NameNotFoundException: ConnectionFactory" Key: JBTM-2446 URL: https://issues.jboss.org/browse/JBTM-2446 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/872/console -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 04:50:03 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 26 Jun 2015 04:50:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2446) Blacktie jatmibroker-xatmi hang with "javax.naming.NameNotFoundException: ConnectionFactory" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084184#comment-13084184 ] Amos Feng commented on JBTM-2446: --------------------------------- It looks like the messaging subsystem has been removed to the legacy. So that it needs to update to use the messaging-activemq with JBTM-2442 > Blacktie jatmibroker-xatmi hang with "javax.naming.NameNotFoundException: ConnectionFactory" > -------------------------------------------------------------------------------------------- > > Key: JBTM-2446 > URL: https://issues.jboss.org/browse/JBTM-2446 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/PROFILE=BLACKTIE,jdk=jdk8.latest,label=linux64el6/872/console -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 04:55:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 26 Jun 2015 04:55:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2442) Update to use activemq-messaging subsystem in the standalone-blacktie.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2442: ---------------------------- Fix Version/s: 5.next (was: 5.later) > Update to use activemq-messaging subsystem in the standalone-blacktie.xml > ------------------------------------------------------------------------- > > Key: JBTM-2442 > URL: https://issues.jboss.org/browse/JBTM-2442 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > currently the wildfly 10.0.0.Alpha4 changes to use the activemq-messaging and the default resource adapter of the MDB changed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 04:55:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 26 Jun 2015 04:55:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2442) Update to use activemq-messaging subsystem in the standalone-blacktie.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2442: ---------------------------- Priority: Blocker (was: Major) > Update to use activemq-messaging subsystem in the standalone-blacktie.xml > ------------------------------------------------------------------------- > > Key: JBTM-2442 > URL: https://issues.jboss.org/browse/JBTM-2442 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > currently the wildfly 10.0.0.Alpha4 changes to use the activemq-messaging and the default resource adapter of the MDB changed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 05:02:03 2015 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 26 Jun 2015 05:02:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2444) jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084187#comment-13084187 ] Gytis Trikleris commented on JBTM-2444: --------------------------------------- REAT-AT Bridge test with JMS fails now. It's because they haven't updated standalone-rts.xml and standalone-xts.xml configurations to use ActiveMQ. I've checked it locally and that is the issue. Seems that they have planned backwards compatibility, but it's not yet implemented: https://issues.jboss.org/browse/WFLY-4586. I have notified Jeff about this: https://issues.jboss.org/browse/WFLY-4584. > jta-1_2-in-wildfly quickstart is failing - presume related to update from HornetQ to ActiveMQ > --------------------------------------------------------------------------------------------- > > Key: JBTM-2444 > URL: https://issues.jboss.org/browse/JBTM-2444 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Priority: Blocker > Fix For: 5.next > > > {code} > Running org.jboss.narayana.quickstarts.jta.TestCase > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 18.563 sec <<< FAILURE! > Results : > Tests in error: > org.jboss.narayana.quickstarts.jta.TestCase: Cannot deploy: test.war > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > {code} > The log file says: > {code} > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYMSGAMQ0055: Could not parse file /home/hudson/workspace/narayana-quickstarts/wildfly-10.0.0.Alpha4-SNAPSHOT/standalone/tmp/vfs/temp/temp174d29cf17a7dbea/content-a7b7e754b2627502/WEB-INF/test-jms.xml > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[23,1] > Message: Unexpected element '{urn:jboss:messaging-deployment:1.0}messaging-deployment'"}} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42) > at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55) > at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > ... 96 more > {code} > Which leads me to believe it is likely due to the parsing in test-jms.xml. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 06:28:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Jun 2015 06:28:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084209#comment-13084209 ] Tom Jenkinson commented on JBTM-2238: ------------------------------------- Work in progress quickstart: https://github.com/jbosstm/quickstart/pull/128/ > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Fri Jun 26 07:42:02 2015 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 26 Jun 2015 07:42:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2447) BlackTie build failure - requires investigation In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2447: ----------------------------------- Summary: BlackTie build failure - requires investigation Key: JBTM-2447 URL: https://issues.jboss.org/browse/JBTM-2447 Project: JBoss Transaction Manager Issue Type: Bug Components: BlackTie Reporter: Tom Jenkinson Assignee: Amos Feng http://albany.eng.hst.ams2.redhat.com/job/narayana/745/PROFILE=BLACKTIE,jdk=jdk7.latest,label=linux32el6/console -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 01:34:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Jun 2015 01:34:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2448) Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT In-Reply-To: References: Message-ID: Amos Feng created JBTM-2448: ------------------------------- Summary: Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT Key: JBTM-2448 URL: https://issues.jboss.org/browse/JBTM-2448 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 01:59:01 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Jun 2015 01:59:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2448) Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2448: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/879 > Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT > ----------------------------------------- > > Key: JBTM-2448 > URL: https://issues.jboss.org/browse/JBTM-2448 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 03:29:02 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Jun 2015 03:29:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2448) Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2448: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade wildfly to 10.0.0.Alpha5-SNAPSHOT > ----------------------------------------- > > Key: JBTM-2448 > URL: https://issues.jboss.org/browse/JBTM-2448 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 04:58:02 2015 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 29 Jun 2015 04:58:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2398) Support VolatileStore.allObjUids In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2398: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Support VolatileStore.allObjUids > --------------------------------- > > Key: JBTM-2398 > URL: https://issues.jboss.org/browse/JBTM-2398 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Performance Testing > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.later > > > This method is used by REST-AT and would be a useful addition for baselining the performance of the coordinator for comparison with non transactional and empty transaction requests. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Mon Jun 29 07:56:05 2015 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Jun 2015 07:56:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2442) Update to use activemq-messaging subsystem in the standalone-blacktie.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2442: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/880 > Update to use activemq-messaging subsystem in the standalone-blacktie.xml > ------------------------------------------------------------------------- > > Key: JBTM-2442 > URL: https://issues.jboss.org/browse/JBTM-2442 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration, BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.next > > > currently the wildfly 10.0.0.Alpha4 changes to use the activemq-messaging and the default resource adapter of the MDB changed. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Tue Jun 30 11:12:03 2015 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Tue, 30 Jun 2015 11:12:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2428) JTS client side transaction context seems not being propagated to EAP server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski reassigned JBTM-2428: ------------------------------------ Assignee: Ond?ej Chaloupka (was: Tomasz Adamski) > JTS client side transaction context seems not being propagated to EAP server > ---------------------------------------------------------------------------- > > Key: JBTM-2428 > URL: https://issues.jboss.org/browse/JBTM-2428 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.1.1 > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > It seems that transaction context is not propagated when JTS transaction is started on client. > This was working for EAP 6.4 where iiop corba implementation was used. The testing client is based on guide [1]. > The call from client to server via IIOP [4] works fine but when I'm trying to start transaction on client side and then expecting being propagated to server, server proclaims that there is no txn in the context. > This is how the orb is set up [2] > This is how the transaction is started [3] > This is how the remote call on ejb app server is done [4] > [1] https://developer.jboss.org/wiki/TransactionPropagationWithJBoss > [2] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l530 > [3] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/base/TestBaseOneServer.java;h=ed9b30aabe11fdb5f3290763beb167182a22a819;hb=HEAD#l511 > [4] https://code.engineering.redhat.com/gerrit/gitweb?p=jbossqe-eap-tests-transactions.git;a=blob;f=jbossts/src/test/java/org/jboss/as/test/jbossts/client/TxUtil.java;h=5dd55e22a52df6fd3845b1de5134f436f721a437;hb=HEAD#l69 > [5] [com.arjuna.ats.jts] (main) ARJUNA022251: The ORBManager is already associated with an ORB/OA. > FINE [javax.enterprise.resource.corba._DEFAULT_.rpc.protocol] (main) "IOP01600014: (BAD_INV_ORDER) Cannot access this attribute or method at this point": org.omg.CORBA.BAD_INV_ORDER: vmcid: OMG minor code: 14 completed: No > -- or -- > FINE [javax.enterprise.resource.corba._CORBA_.rpc.presentation] (main) "IOP00110227: (BAD_PARAM) ORBDynamicStubFactoryFactoryClass property had value com.sun.corba.se.impl.presentation.rmi.bcel.StubFactoryFactoryBCELImpl, which could not be loaded by the ORB ClassLoader": org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 227 completed: No -- This message was sent by Atlassian JIRA (v6.3.15#6346)