From issues at jboss.org Tue Mar 1 06:06:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 1 Mar 2016 06:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2631) UidTest qa test suite (with the journal store) failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2631: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > UidTest qa test suite (with the journal store) failures > ------------------------------------------------------- > > Key: JBTM-2631 > URL: https://issues.jboss.org/browse/JBTM-2631 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Attachments: testoutput.jacorb.hqstore.tar > > > CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-hqstore/151/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/ failed with various uid test failures: > {quote} > txcore Uid_Test011 Fail (0m18.180s) > txcore Uid_Test011 Fail (0m19.431s) > txcore Uid_Test012 Fail (0m20.850s) > txcore Uid_Test004 Fail (0m11.566s) > txcore Uid_Test005 Fail (0m12.343s) > txcore Uid_Test006 Fail (0m12.062s) > txcore Uid_Test007 Fail (0m15.742s) > txcore Uid_Test008 Fail (0m16.908s) > txcore Uid_Test009 Fail (0m17.282s) > txcore_lockrecord LockRecord_Thread_Test036a Fail (8m12.773s) > txcore_lockrecord LockRecord_Thread_Test036b Fail (8m10.265s) > txcore_lockrecord LockRecord_Thread_Test048a Fail (8m11.115s) > txcore_lockrecord LockRecord_Thread_Test048b Fail (8m7.376s) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 07:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Mar 2016 07:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2583: -------------------------------- Summary: Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection (was: Try to contact the transaction status connection manager to determine if a transaction containing XAResources is still in-flight before relying on orphan detection) > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2583 > URL: https://issues.jboss.org/browse/JBTM-2583 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.later > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > > * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:16:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Mar 2016 09:16:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2458 started by Tom Jenkinson. ------------------------------------------- > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:17:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Mar 2016 09:17:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2458 stopped by Tom Jenkinson. ------------------------------------------- > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:23:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 1 Mar 2016 09:23:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2458: ----------------------------------- Assignee: Gytis Trikleris (was: Tom Jenkinson) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:27:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Mar 2016 09:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2622 started by Gytis Trikleris. --------------------------------------------- > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:28:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Mar 2016 09:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170209#comment-13170209 ] Gytis Trikleris commented on JBTM-2622: --------------------------------------- Pull request for code comments: https://github.com/gytis/narayana/pull/4 > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 1 09:28:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 1 Mar 2016 09:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2622: ---------------------------------- Comment: was deleted (was: Pull request for code comments: https://github.com/gytis/narayana/pull/4) > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 02:37:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 02:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-855) Create an example showing integration with Spring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-855: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Create an example showing integration with Spring > ------------------------------------------------- > > Key: JBTM-855 > URL: https://issues.jboss.org/browse/JBTM-855 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The main thing is to show the config but we need to provide an example that shows how to ensure the XAResources are available for recovery -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:52:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:52:00 -0500 (EST) 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 ] Tom Jenkinson updated JBTM-1359: -------------------------------- Status: Open (was: Pull Request Sent) > 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 > Priority: Optional > 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.4.11#64026) From issues at jboss.org Wed Mar 2 09:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2203: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2583: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2583 > URL: https://issues.jboss.org/browse/JBTM-2583 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > > * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:54:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:54:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2583: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2583 > URL: https://issues.jboss.org/browse/JBTM-2583 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > > * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2598) Merge in BlackTie Javadocs to main Narayana javadocs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2598: -------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/977 > Merge in BlackTie Javadocs to main Narayana javadocs > ---------------------------------------------------- > > Key: JBTM-2598 > URL: https://issues.jboss.org/browse/JBTM-2598 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System, Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 6.later > > > The BlackTie javadocs are still separate http://narayana.io/documentation/index.html - it would be useful to ensure that they are in the same place as the rest of the Narayana javadocs. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:56:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2511) Benchmark failure testing REST-AT with undertow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2511: -------------------------------- Status: Open (was: Pull Request Sent) > Benchmark failure testing REST-AT with undertow > ----------------------------------------------- > > Key: JBTM-2511 > URL: https://issues.jboss.org/browse/JBTM-2511 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing, REST > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > > The REST-AT benchmark tests are failing: > http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-benchmarks/37/ > and the failure is: > bq. Caused by: javax.ws.rs.ServiceUnavailableException: HTTP 503 Service Unavailable > whilst sending a request to a JAX-RS service. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:58:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Status: Open (was: Pull Request Sent) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 09:58:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 09:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2245 stopped by Tom Jenkinson. ------------------------------------------- > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration, XTS > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2630) Downgrade maven assembly plugin to 2.4 in BlackTie In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2630. ------------------------------- > Downgrade maven assembly plugin to 2.4 in BlackTie > -------------------------------------------------- > > Key: JBTM-2630 > URL: https://issues.jboss.org/browse/JBTM-2630 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.0.Final > > > Currently the 2.5.5 maven assembly plugin does not work on EL5. > The workaround is to downgrade to 2.4 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2628) QA testsuite logging does not use log4j In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2628. ------------------------------- > QA testsuite logging does not use log4j > --------------------------------------- > > Key: JBTM-2628 > URL: https://issues.jboss.org/browse/JBTM-2628 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.0.Final > > > The qa testsuite does not add log4j.jar to the classpath so we default to the jdk logger with the result that we do not get the desired log line formatting (such as including the thread name). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2617) Add recovery support to JMS integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2617. ------------------------------- > Add recovery support to JMS integration > --------------------------------------- > > Key: JBTM-2617 > URL: https://issues.jboss.org/browse/JBTM-2617 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2616) Implement JMS integration classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2616. ------------------------------- > Implement JMS integration classes > --------------------------------- > > Key: JBTM-2616 > URL: https://issues.jboss.org/browse/JBTM-2616 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.0.Final > > > Both Spring and Spring Boot requires ConnectionFactory, Connection, Session implementation which should handle the transaction related tasks when using JMS e.g. enlisting xa resources, registering synchronizations etc. > This should be somethings similar to the ConnectionManager and ConnectionImple used by the transactional driver. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2583) Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2583. ------------------------------- > Use the local ActionStatusService to determine if a transaction containing XAResources is still in-flight before relying on orphan detection > -------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2583 > URL: https://issues.jboss.org/browse/JBTM-2583 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.0.Final > > > Currently we use a timeout based system to determine if prepared Xids that a ResourceManager knows about but where the transaction is not prepared yet are the result of a pre-prepare crash or whether it is just slow progress of the resources/transaction manager. > This issue is to record an enhancement to the recovery manager for XAResources to attempt to contact the transaction manager to determine if an Xid is indoubt before rolling it back. > > * In the case where the recovery manager and transaction manager are co-located this negates the need for a timeout based process entirely > * In the case where the recovery manager and transaction manager are not in the same JVM process, the current behaviour of timeout based orphan detection MUST still be employed -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-855) Create an example showing integration with Spring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-855. ------------------------------ > Create an example showing integration with Spring > ------------------------------------------------- > > Key: JBTM-855 > URL: https://issues.jboss.org/browse/JBTM-855 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.3.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > The main thing is to show the config but we need to provide an example that shows how to ensure the XAResources are available for recovery -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2629: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2626: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2624: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2623: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2622: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2619) Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2619: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) > -------------------------------------------------------------------------- > > Key: JBTM-2619 > URL: https://issues.jboss.org/browse/JBTM-2619 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > It should be with the recovery example -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:04:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:04:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2606: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2605) Narayana Spring integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2605: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Narayana Spring integration > --------------------------- > > Key: JBTM-2605 > URL: https://issues.jboss.org/browse/JBTM-2605 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, Documentation, JTA > Reporter: Gytis Trikleris > Fix For: 5.next > > > This is a wrapper for all subtasks related with Spring integration. > As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2571: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2553: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2498: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2480: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2458: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Write an atomic app that uses JTS and JacORB containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2298: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Write an atomic app that uses JTS and JacORB containers > ------------------------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2206: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2203: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2115: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 2 10:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 2 Mar 2016 10:05:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-223: ------------------------------- Fix Version/s: 5.next (was: 5.3.0.Final) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:00:05 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 3 Mar 2016 10:00:05 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #986 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2629: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2626: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2624: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2623: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2622: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2619) Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2619: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) > -------------------------------------------------------------------------- > > Key: JBTM-2619 > URL: https://issues.jboss.org/browse/JBTM-2619 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > It should be with the recovery example -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2606: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2605) Narayana Spring integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2605: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Narayana Spring integration > --------------------------- > > Key: JBTM-2605 > URL: https://issues.jboss.org/browse/JBTM-2605 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, Documentation, JTA > Reporter: Gytis Trikleris > Fix For: 5.next > > > This is a wrapper for all subtasks related with Spring integration. > As per Tom's request we should improve Narayana integration with Spring and Spring Boot. Also, provide documentation and quickstarts for it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2571: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2553: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2498: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2480: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2458: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Think of the possibility to improve Compensations API with lambdas > ------------------------------------------------------------------ > > Key: JBTM-2458 > URL: https://issues.jboss.org/browse/JBTM-2458 > Project: JBoss Transaction Manager > Issue Type: Task > Components: TXFramework > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation. > We should try to think of the best API changes to introduce that. > We could rewrite MongoDB quickstart to make it easier to visualise the difference. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Write an atomic app that uses JTS and JacORB containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2298: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Write an atomic app that uses JTS and JacORB containers > ------------------------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2206: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2203) Remove ReentrantLock from StateManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2203: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Remove ReentrantLock from StateManager > -------------------------------------- > > Key: JBTM-2203 > URL: https://issues.jboss.org/browse/JBTM-2203 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Remove unused lock from StateManager, and add the access methods to LockManager instead -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:02 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2115: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:03 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-1804: ---------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 10:03:03 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 3 Mar 2016 10:03:03 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-223: --------------------------------- Fix Version/s: 5.next (was: 5.3.1.Final) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 16:33:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Mar 2016 16:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved JBEAP-3667 to JBTM-2632: -------------------------------------------- Project: JBoss Transaction Manager (was: JBoss Enterprise Application Platform) Key: JBTM-2632 (was: JBEAP-3667) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Recovery (was: Transactions) Target Release: (was: 7.backlog.GA) Affects Version/s: (was: 7.backlog.GA) > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 3 16:33:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 3 Mar 2016 16:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2632: -------------------------------- Fix Version/s: 5.next > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 05:06:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Fri, 4 Mar 2016 05:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2633) Arquillian server startup timeout should be configurable in tests In-Reply-To: References: Message-ID: Ond?ej Chaloupka created JBTM-2633: -------------------------------------- Summary: Arquillian server startup timeout should be configurable in tests Key: JBTM-2633 URL: https://issues.jboss.org/browse/JBTM-2633 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Affects Versions: 5.2.14.Final Reporter: Ond?ej Chaloupka Assignee: Ond?ej Chaloupka Arquillian configuration for tests which lays in _arquillian.xml_ currently does not permit changing timeou for server startup. Default timeout for server startup is 60 seconds. If server is not up and running till that time Arquillian stops the serve process and {{LifecycleException}} is thrown informing that server was not started. If tests (like txbridge or xts) are run with container which uses _jdbc object store_ and connection to database is slow. It could happen that 60 seconds is not enough for serve being started and tests start to fail. The easy solution is to wait a bit more for server would be started. Then add configuration property {{startupTimeoutInSeconds}} to {{arquillian.xml}} files which are configured to start jboss/wildfly server and let user to configure the option. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 05:09:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Fri, 4 Mar 2016 05:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2633) Arquillian server startup timeout should be configurable in tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ond?ej Chaloupka created pull request #987 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Arquillian server startup timeout should be configurable in tests > ----------------------------------------------------------------- > > Key: JBTM-2633 > URL: https://issues.jboss.org/browse/JBTM-2633 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > Arquillian configuration for tests which lays in _arquillian.xml_ currently does not permit changing timeou for server startup. Default timeout for server startup is 60 seconds. If server is not up and running till that time Arquillian stops the serve process and {{LifecycleException}} is thrown informing that server was not started. > If tests (like txbridge or xts) are run with container which uses _jdbc object store_ and connection to database is slow. It could happen that 60 seconds is not enough for serve being started and tests start to fail. The easy solution is to wait a bit more for server would be started. > Then add configuration property {{startupTimeoutInSeconds}} to {{arquillian.xml}} files which are configured to start jboss/wildfly server and let user to configure the option. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 09:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Mar 2016 09:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2626 started by Tom Jenkinson. ------------------------------------------- > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 09:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Mar 2016 09:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2626: ----------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 09:36:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Mar 2016 09:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2626) Journal Store QA test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2626. --------------------------------- Resolution: Done > Journal Store QA test failures > ------------------------------ > > Key: JBTM-2626 > URL: https://issues.jboss.org/browse/JBTM-2626 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: jstack.25002.jacorb > > > There was a single test failure on each of the following CI runs: > crashrecovery05_2 CrashRecovery05_2_Test080 failed on the idlj run on the jobs: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/147/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/console > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/PROFILE=QA_JTS_JDKORB,jdk=jdk8.latest,label=linux/148/console > and jtatests01 JTATests01_Test006 failed on the jacorb run of job: > http://albany.eng.hst.ams2.redhat.com/job/narayana-hqstore/149/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/console -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 10:31:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 4 Mar 2016 10:31:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2634: ------------------------------------- Summary: Create Narayana Spring Boot starter quickstart Key: JBTM-2634 URL: https://issues.jboss.org/browse/JBTM-2634 Project: JBoss Transaction Manager Issue Type: Sub-task Components: Demonstrator, JTA Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 10:32:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 4 Mar 2016 10:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2606 stopped by Gytis Trikleris. --------------------------------------------- > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 10:32:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 4 Mar 2016 10:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2634 started by Gytis Trikleris. --------------------------------------------- > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 4 12:39:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 4 Mar 2016 12:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2633) Arquillian server startup timeout should be configurable in tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2633: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > Arquillian server startup timeout should be configurable in tests > ----------------------------------------------------------------- > > Key: JBTM-2633 > URL: https://issues.jboss.org/browse/JBTM-2633 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > Fix For: 5.next > > > Arquillian configuration for tests which lays in _arquillian.xml_ currently does not permit changing timeou for server startup. Default timeout for server startup is 60 seconds. If server is not up and running till that time Arquillian stops the serve process and {{LifecycleException}} is thrown informing that server was not started. > If tests (like txbridge or xts) are run with container which uses _jdbc object store_ and connection to database is slow. It could happen that 60 seconds is not enough for serve being started and tests start to fail. The easy solution is to wait a bit more for server would be started. > Then add configuration property {{startupTimeoutInSeconds}} to {{arquillian.xml}} files which are configured to start jboss/wildfly server and let user to configure the option. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 00:24:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 7 Mar 2016 00:24:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2619) Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #159 in GitHub --------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Create a quickstart to show using of the narayana-osgi-jta bundle (karaf) > -------------------------------------------------------------------------- > > Key: JBTM-2619 > URL: https://issues.jboss.org/browse/JBTM-2619 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > It should be with the recovery example -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 7 05:43:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 7 Mar 2016 05:43:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2635) TXBridge OutboundBasicTests hanging In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2635: ------------------------------------- Summary: TXBridge OutboundBasicTests hanging Key: JBTM-2635 URL: https://issues.jboss.org/browse/JBTM-2635 Project: JBoss Transaction Manager Issue Type: Bug Components: TxBridge Affects Versions: 5.3.1.Final Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Thread dump {code} Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode): "Thread-16" #41 prio=5 os_prio=0 tid=0x0000000009fb6000 nid=0x6f30 runnable [0x00002b5477ed7000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:255) at java.io.BufferedInputStream.read1(BufferedInputStream.java:284) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) - locked <0x00000000a46321e0> (a java.lang.UNIXProcess$ProcessPipeInputStream) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) - locked <0x00000000a4632238> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:161) at java.io.BufferedReader.readLine(BufferedReader.java:324) - locked <0x00000000a4632238> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:389) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66) "Thread-15" #40 prio=5 os_prio=0 tid=0x0000000009f86000 nid=0x6f2d runnable [0x00002b5477dd6000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:255) at java.io.BufferedInputStream.read1(BufferedInputStream.java:284) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) - locked <0x00000000a46782f8> (a java.lang.UNIXProcess$ProcessPipeInputStream) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) - locked <0x00000000a4827108> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:161) at java.io.BufferedReader.readLine(BufferedReader.java:324) - locked <0x00000000a4827108> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:389) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:66) "ThreadedStreamConsumer" #39 prio=5 os_prio=0 tid=0x000000000a028000 nid=0x6f2b waiting on condition [0x00002b5477cd5000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a4678188> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:68) at java.lang.Thread.run(Thread.java:745) "pool-1-thread-1" #22 prio=5 os_prio=0 tid=0x000000000b4a2000 nid=0x4ea3 in Object.wait() [0x00002b5477bd4000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000a46782b8> (a java.lang.UNIXProcess) at java.lang.Object.wait(Object.java:502) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396) - locked <0x00000000a46782b8> (a java.lang.UNIXProcess) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:202) at org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:141) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:471) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:380) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$300(ForkStarter.java:88) at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:315) at org.apache.maven.plugin.surefire.booterclient.ForkStarter$2.call(ForkStarter.java:306) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745) "resolver-4" #21 daemon prio=5 os_prio=0 tid=0x000000000bc90000 nid=0x4ea2 waiting on condition [0x00002b5477a3e000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a856fb90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "resolver-3" #20 daemon prio=5 os_prio=0 tid=0x0000000009fab800 nid=0x4ea1 waiting on condition [0x00002b547793d000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a856fb90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "resolver-2" #19 daemon prio=5 os_prio=0 tid=0x0000000009f0a800 nid=0x4ea0 waiting on condition [0x00002b547711b000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a856fb90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "resolver-1" #18 daemon prio=5 os_prio=0 tid=0x000000000a40f000 nid=0x4e9f waiting on condition [0x00002b547701a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a856fb90> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "process reaper" #11 daemon prio=10 os_prio=0 tid=0x000000000a9c8000 nid=0x4e94 runnable [0x00002b5476f19000] java.lang.Thread.State: RUNNABLE at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.lambda$initStreams$273(UNIXProcess.java:290) at java.lang.UNIXProcess$$Lambda$7/594570680.run(Unknown Source) 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:745) "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x0000000009431800 nid=0x4e90 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #7 daemon prio=9 os_prio=0 tid=0x000000000942a800 nid=0x4e8f waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00000000093dc000 nid=0x4e8e waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #5 daemon prio=9 os_prio=0 tid=0x00000000093d9800 nid=0x4e8d runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Surrogate Locker Thread (Concurrent GC)" #4 daemon prio=9 os_prio=0 tid=0x00000000093d8800 nid=0x4e8c waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x000000000939a000 nid=0x4e8b in Object.wait() [0x00002b547226a000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000a80443d0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000a80443d0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x0000000009398000 nid=0x4e8a in Object.wait() [0x00002b5472169000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000a803c3d0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x00000000a803c3d0> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=0 tid=0x00000000092ea800 nid=0x4e86 waiting on condition [0x00002b545d802000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000a9237408> (a java.util.concurrent.FutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:327) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:178) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:990) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:824) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:722) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) "VM Thread" os_prio=0 tid=0x0000000009393000 nid=0x4e89 runnable "Gang worker#0 (Parallel GC Threads)" os_prio=0 tid=0x00000000092fb800 nid=0x4e87 runnable "Concurrent Mark-Sweep GC Thread" os_prio=0 tid=0x000000000931e800 nid=0x4e88 runnable "VM Periodic Task Thread" os_prio=0 tid=0x0000000009434800 nid=0x4e91 waiting on condition 2016-03-07 10:39:06 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode): "Remoting "endpoint" task-9" #187 daemon prio=5 os_prio=0 tid=0x00000000133d5800 nid=0x73ce waiting on condition [0x00002aeb308f7000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-8" #186 daemon prio=5 os_prio=0 tid=0x000000001372c800 nid=0x73cd waiting on condition [0x00002aeb2f2e3000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "management-client-thread 5-2" #184 prio=5 os_prio=0 tid=0x000000001366d000 nid=0x73a4 waiting on condition [0x00002aeb2eedf000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c207d548> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) "Remoting "endpoint" task-7" #181 daemon prio=5 os_prio=0 tid=0x0000000013329800 nid=0x73a2 waiting on condition [0x00002aeb2feef000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-6" #180 daemon prio=5 os_prio=0 tid=0x0000000013329000 nid=0x73a0 waiting on condition [0x00002aeb2e47f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-5" #179 daemon prio=5 os_prio=0 tid=0x0000000013328000 nid=0x739f waiting on condition [0x00002aeb2fff0000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-4" #178 daemon prio=5 os_prio=0 tid=0x0000000013327800 nid=0x739e waiting on condition [0x00002aeb31602000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-3" #177 daemon prio=5 os_prio=0 tid=0x0000000013326800 nid=0x739d waiting on condition [0x00002aeb2e989000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-2" #176 daemon prio=5 os_prio=0 tid=0x000000001328b000 nid=0x739c waiting on condition [0x00002aeb307f6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" task-1" #175 daemon prio=5 os_prio=0 tid=0x000000001328a000 nid=0x739b waiting on condition [0x00002aeb2f0e1000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c20bff98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "endpoint" I/O-1" #174 daemon prio=5 os_prio=0 tid=0x000000001328d000 nid=0x739a runnable [0x00002aeb2f7e8000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0x00000000c20c0428> (a sun.nio.ch.Util$2) - locked <0x00000000c20c0418> (a java.util.Collections$UnmodifiableSet) - locked <0x00000000c20c0300> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.xnio.nio.WorkerThread.run(WorkerThread.java:502) "management-client-thread 5-1" #173 prio=5 os_prio=0 tid=0x000000001328c000 nid=0x7397 waiting on condition [0x00002aeb305f4000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c207d548> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) "Remoting "management-client" task-16" #172 prio=5 os_prio=0 tid=0x000000001339c000 nid=0x738d waiting on condition [0x00002aeb2f6e7000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-15" #171 prio=5 os_prio=0 tid=0x000000001339d800 nid=0x738c waiting on condition [0x00002aeb306f5000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-14" #170 prio=5 os_prio=0 tid=0x0000000013e3c800 nid=0x738a waiting on condition [0x00002aeb2f8e9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-13" #169 prio=5 os_prio=0 tid=0x0000000013441000 nid=0x7389 waiting on condition [0x00002aeb2f3e4000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-12" #168 prio=5 os_prio=0 tid=0x0000000014229800 nid=0x7388 waiting on condition [0x00002aeb2f5e6000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-11" #167 prio=5 os_prio=0 tid=0x0000000013a53800 nid=0x7387 waiting on condition [0x00002aeb302f1000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-10" #166 prio=5 os_prio=0 tid=0x0000000013472800 nid=0x7386 waiting on condition [0x00002aeb2fdee000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-9" #165 prio=5 os_prio=0 tid=0x00000000134a9000 nid=0x7383 waiting on condition [0x00002aeb2fbec000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-8" #164 prio=5 os_prio=0 tid=0x00000000131dc000 nid=0x737f waiting on condition [0x00002aeb2f1e2000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-7" #163 prio=5 os_prio=0 tid=0x0000000013474800 nid=0x737a waiting on condition [0x00002aeb31703000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-6" #162 prio=5 os_prio=0 tid=0x0000000013b1b800 nid=0x7377 waiting on condition [0x00002aeb30af9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-5" #161 prio=5 os_prio=0 tid=0x000000001339e800 nid=0x7370 waiting on condition [0x00002aeb2fced000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-4" #160 prio=5 os_prio=0 tid=0x0000000013e3a000 nid=0x736a waiting on condition [0x00002aeb2f9ea000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-3" #159 prio=5 os_prio=0 tid=0x0000000014228000 nid=0x735f waiting on condition [0x00002aeb2faeb000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-2" #158 prio=5 os_prio=0 tid=0x0000000013250000 nid=0x735c waiting on condition [0x00002aeb2efe0000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" task-1" #157 prio=5 os_prio=0 tid=0x0000000013516000 nid=0x735a waiting on condition [0x00002aeb309f8000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c2081de8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "Remoting "management-client" I/O-1" #156 prio=5 os_prio=0 tid=0x0000000013344000 nid=0x72f5 runnable [0x00002aeb2f4e5000] java.lang.Thread.State: RUNNABLE at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) - locked <0x00000000c2082260> (a sun.nio.ch.Util$2) - locked <0x00000000c2082250> (a java.util.Collections$UnmodifiableSet) - locked <0x00000000c2082138> (a sun.nio.ch.EPollSelectorImpl) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at org.xnio.nio.WorkerThread.run(WorkerThread.java:502) "RMI Scheduler(0)" #46 daemon prio=5 os_prio=0 tid=0x0000000012e95000 nid=0x7003 waiting on condition [0x00002aeb30ffe000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000c1e599c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) "GC Daemon" #44 daemon prio=2 os_prio=0 tid=0x000000001311c000 nid=0x6ff2 in Object.wait() [0x00002aeb30dfc000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at sun.misc.GC$Daemon.run(GC.java:117) - locked <0x00000000c1f87830> (a sun.misc.GC$LatencyLock) "RMI Reaper" #43 prio=5 os_prio=0 tid=0x0000000013119800 nid=0x6ff1 in Object.wait() [0x00002aeb30cfb000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000c1e3f620> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000c1e3f620> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351) at java.lang.Thread.run(Thread.java:745) "RMI TCP Accept-0" #42 daemon prio=5 os_prio=0 tid=0x0000000013117800 nid=0x6ff0 runnable [0x00002aeb30bfa000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) at java.net.ServerSocket.implAccept(ServerSocket.java:545) at java.net.ServerSocket.accept(ServerSocket.java:513) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372) at java.lang.Thread.run(Thread.java:745) "process reaper" #10 daemon prio=10 os_prio=0 tid=0x0000000013502800 nid=0x6f3c runnable [0x00002aeb2e37e000] java.lang.Thread.State: RUNNABLE at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.lambda$initStreams$273(UNIXProcess.java:290) at java.lang.UNIXProcess$$Lambda$7/1233990028.run(Unknown Source) 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:745) "RMI TCP Accept-1199" #9 daemon prio=5 os_prio=0 tid=0x000000001413c800 nid=0x6f39 runnable [0x00002aeb2e10e000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409) at java.net.ServerSocket.implAccept(ServerSocket.java:545) at java.net.ServerSocket.accept(ServerSocket.java:513) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372) at java.lang.Thread.run(Thread.java:745) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x0000000012b02000 nid=0x6f37 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x0000000012afb000 nid=0x6f36 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x0000000012aac800 nid=0x6f35 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x0000000012aab000 nid=0x6f34 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x0000000012a6c800 nid=0x6f33 in Object.wait() [0x00002aeb29f40000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000000c1c25980> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x0000000012a6a800 nid=0x6f32 in Object.wait() [0x00002aeb29e3f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157) - locked <0x00000000c1c25b38> (a java.lang.ref.Reference$Lock) "main" #1 prio=5 os_prio=0 tid=0x00000000129da000 nid=0x6f2f in Object.wait() [0x00002aeb19032000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396) - locked <0x00000000c207f620> (a java.lang.UNIXProcess) at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.stopInternal(ManagedDeployableContainer.java:275) at org.jboss.as.arquillian.container.CommonDeployableContainer.stop(CommonDeployableContainer.java:122) at org.jboss.arquillian.container.impl.ContainerImpl.stop(ContainerImpl.java:217) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:178) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:172) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.stopContainer(ContainerLifecycleController.java:171) 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.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.container.ClientContainerController.stop(ClientContainerController.java:204) at org.jboss.jbossts.txbridge.tests.outbound.junit.OutboundBasicTests.tearDown(OutboundBasicTests.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:459) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:80) 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createAfterContext(ContainerEventController.java:134) 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.junit.extension.UpdateTestResultBeforeAfter.update(UpdateTestResultBeforeAfter.java:54) 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.createTestContext(TestContextHandler.java:130) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) 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.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) 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.after(EventTestRunnerAdaptor.java:122) at org.jboss.arquillian.junit.Arquillian$5$1.evaluate(Arquillian.java:264) 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$5.evaluate(Arquillian.java:259) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72) 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.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.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.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.createTestContext(TestContextHandler.java:130) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) 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.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) 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.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) "VM Thread" os_prio=0 tid=0x0000000012a65800 nid=0x6f31 runnable "VM Periodic Task Thread" os_prio=0 tid=0x0000000012b05800 nid=0x6f38 waiting on condition JNI global references: 255 Heap par new generation total 28864K, used 12323K [0x00000000a2a00000, 0x00000000a4950000, 0x00000000a7d30000) eden space 25664K, 35% used [0x00000000a2a00000, 0x00000000a32e8dc0, 0x00000000a4310000) from space 3200K, 100% used [0x00000000a4630000, 0x00000000a4950000, 0x00000000a4950000) to space 3200K, 0% used [0x00000000a4310000, 0x00000000a4310000, 0x00000000a4630000) concurrent mark-sweep generation total 64192K, used 30441K [0x00000000a7d30000, 0x00000000abbe0000, 0x0000000100000000) Metaspace used 26517K, capacity 27428K, committed 27612K, reserved 1073152K class space used 3152K, capacity 3467K, committed 3556K, reserved 1048576K JNI global references: 339 Heap SUREFIRE-859: def new generation total 29056K, used 109K [0x00000000a2a00000, 0x00000000a4980000, 0x00000000c1c00000) SUREFIRE-859: eden space 25856K, 0% used [0x00000000a2a00000, 0x00000000a2a1b518, 0x00000000a4340000) SUREFIRE-859: from space 3200K, 0% used [0x00000000a4340000, 0x00000000a4340000, 0x00000000a4660000) SUREFIRE-859: to space 3200K, 0% used [0x00000000a4660000, 0x00000000a4660000, 0x00000000a4980000) SUREFIRE-859: tenured generation total 64192K, used 5286K [0x00000000c1c00000, 0x00000000c5ab0000, 0x0000000100000000) SUREFIRE-859: the space 64192K, 8% used [0x00000000c1c00000, 0x00000000c2129ab8, 0x00000000c2129c00, 0x00000000c5ab0000) SUREFIRE-859: Metaspace used 19536K, capacity 19712K, committed 20096K, reserved 1067008K SUREFIRE-859: class space used 2501K, capacity 2576K, committed 2688K, reserved 1048576K FATAL: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid stream header: 31362D30 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid stream header: 31362D30 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:742) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168) at com.sun.proxy.$Proxy45.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:956) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:756) at hudson.model.Build$BuildExecution.build(Build.java:198) at hudson.model.Build$BuildExecution.doRun(Build.java:159) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1706) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:232) Caused by: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid stream header: 31362D30 at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:805) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.StreamCorruptedException: invalid stream header: 31362D30 at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:806) at java.io.ObjectInputStream.(ObjectInputStream.java:299) at hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 04:51:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Mar 2016 04:51:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 & Test077 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2196: ----------------------------------- Summary: QA suite failure: CrashRecovery05_2_Test034 & Test077 (was: QA suite failure: CrashRecovery05_2_Test034) > QA suite failure: CrashRecovery05_2_Test034 & Test077 > ----------------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test034.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/550/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 04:53:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Mar 2016 04:53:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 & Test077 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2196: ----------------------------------- Attachment: crashrecovery05_2_Test077.tar Another hang > QA suite failure: CrashRecovery05_2_Test034 & Test077 > ----------------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test034.tar, crashrecovery05_2_Test077.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/550/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 04:54:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 8 Mar 2016 04:54:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2252) QA suite failure: CrashRecovery05_2_Test030 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2252. ---------------------------------- Resolution: Out of Date > QA suite failure: CrashRecovery05_2_Test030 > -------------------------------------------- > > Key: JBTM-2252 > URL: https://issues.jboss.org/browse/JBTM-2252 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test030.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/638/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 07:05:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Mar 2016 07:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2636: ----------------------------------- Summary: Backport deferred exceptions Key: JBTM-2636 URL: https://issues.jboss.org/browse/JBTM-2636 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Tom Jenkinson Fix For: 4.17.31 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 07:08:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Mar 2016 07:08:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2636: -------------------------------- Description: Includes * JBTM-2110 * https://github.com/jbosstm/narayana/pull/598/commits > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2110 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 07:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Mar 2016 07:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #988 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2110 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 8 09:32:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 8 Mar 2016 09:32:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2636: -------------------------------- Description: Includes * JBTM-2120 * https://github.com/jbosstm/narayana/pull/598/commits was: Includes * JBTM-2110 * https://github.com/jbosstm/narayana/pull/598/commits > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 10:59:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 9 Mar 2016 10:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2636: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 12:35:00 2016 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 9 Mar 2016 12:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: Jesper Pedersen created JBTM-2637: ------------------------------------- Summary: NPE in com.arjuna.ats.jta.xa.XidImple.copy Key: JBTM-2637 URL: https://issues.jboss.org/browse/JBTM-2637 Project: JBoss Transaction Manager Issue Type: Bug Affects Versions: 5.3.1.Final Reporter: Jesper Pedersen {noformat} 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 13:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 9 Mar 2016 13:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174487#comment-13174487 ] Tom Jenkinson commented on JBTM-2637: ------------------------------------- gtrid_length is defined in XA specification as "long gtrid_length; /? value from 1 through 64 ?/" Your implementation is none-compliant! > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 13:19:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 9 Mar 2016 13:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2637. --------------------------------- Resolution: Won't Fix > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 13:44:00 2016 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 9 Mar 2016 13:44:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174493#comment-13174493 ] Jesper Pedersen commented on JBTM-2637: --------------------------------------- IllegalArgumentException would be nicer > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 14:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 9 Mar 2016 14:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174500#comment-13174500 ] Tom Jenkinson commented on JBTM-2637: ------------------------------------- Passing in a none-spec compliant Xid will still have an unexpected outcome whatever the decision. I checked the SPI interfaces in the call stack and it seems this bit of the SPI was not defined (at least from the Java code) as to what the expected outcome would be so NPE is just as valid as IAE. Would an IAE actually help you more than the NPE? > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 14:15:02 2016 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 9 Mar 2016 14:15:02 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174512#comment-13174512 ] Jesper Pedersen commented on JBTM-2637: --------------------------------------- The IAE could have a description of the problem - e.g. "getGlobalTransactionId() is null", and so on. However, not a high priority as this was for a test case where we expect an exception from the usage of Xid instance. > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 9 15:23:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 9 Mar 2016 15:23:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTM-2636: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1316270 Bugzilla Update: Perform > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 04:55:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 10 Mar 2016 04:55:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2637) NPE in com.arjuna.ats.jta.xa.XidImple.copy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174737#comment-13174737 ] Tom Jenkinson commented on JBTM-2637: ------------------------------------- There is already a precedent with what to do with incorrect Xids and so I think the right thing to do would be to change the SPI such that it can throw http://docs.oracle.com/javaee/5/api/javax/transaction/xa/XAException.html#XAER_INVAL That is quite an invasive change though so would need to have a good use case which should likely be discussed on the forum first. > NPE in com.arjuna.ats.jta.xa.XidImple.copy > ------------------------------------------ > > Key: JBTM-2637 > URL: https://issues.jboss.org/browse/JBTM-2637 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.1.Final > Reporter: Jesper Pedersen > > {noformat} > 12:32:13,770 ERROR [executor] Task execution failed for task WorkWrapper at 270dc62b[workManger=org.ironjacamar.core.workmanager.WorkManagerImpl at 274cafa8[id=Default name=Default specCompliant=true shortRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 23733f99 longRunningExecutor=org.ironjacamar.core.workmanager.StatisticsExecutorImpl at 6671a593 xaTerminator=org.ironjacamar.core.tx.narayana.XATerminatorImpl at 152e89a8 validatedWork=[org.ironjacamar.core.workmanager.support.ShortRunningWork] callbackSecurity=DefaultCallback at 57dd454a[mappingRequired=false domain=other defaultPrincipal=null defaultGroups=null principals={} groups={} file=null] securityIntegration=org.ironjacamar.core.security.picketbox.PicketBoxSecurityIntegration at 6d6837df resourceAdapter=null shutdown=false activeWorkWrappers=[] statistics=WorkManagerStatistics at 65e5adc[active=0 successful=0 failed=1 doWorkAccepted=1 doWorkRejected=0 scheduleWorkAccepted=0 scheduleWorkRejected=0 startWorkAccepted=0 startWorkRejected=0]] work=org.ironjacamar.core.workmanager.support.ShortRunningWork at 6dc566d9 xid=org.ironjacamar.core.workmanager.WorkInterfaceTestCase$XidImpl at 61388fbd txTimeout=9223372036854775807 workListener=null workContexts=null exception=javax.resource.spi.work.WorkCompletedException: ARJUNA032022: Unexpected error!, error code: -1]: java.lang.NullPointerException > at com.arjuna.ats.jta.xa.XidImple.copy(XidImple.java:190) > at com.arjuna.ats.jta.xa.XidImple.(XidImple.java:69) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.convertXid(TransactionImporterImple.java:260) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:98) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.importTransaction(TransactionImporterImple.java:69) > at com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator.cancelWork(XATerminator.java:230) > at org.ironjacamar.core.tx.narayana.XATerminatorImpl.cancelWerminatorImpl.java:137) > at org.ironjacamar.core.workmanager.WorkWrapper.cancel(WorkWrapper.java:489) > at org.ironjacamar.core.workmanager.WorkWrapper.run(WorkWrapper.java:233) > at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) > at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) > at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) > at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 05:25:00 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Thu, 10 Mar 2016 05:25:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174765#comment-13174765 ] Daniel Simko commented on JBTM-2578: ------------------------------------ Added workaround to hudson/config_repository/scripts/eap/jbossts/narayana_tests_eap70.sh which downloads required jdbc drivers and modifies default JDBCProfile file in order to fix this job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-70-jbossts-qa-test-ipv6/ {code} junit-jdbc-ncl-testsuite: [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_oracle_thin_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_oracle_thin_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 2,999.919 sec [echo] Running junit test group jdbcresources02_oracle_thin_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_oracle_thin_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 3,046.399 sec [delete] Deleting directory /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_mysql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_mysql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 948.456 sec [echo] Running junit test group jdbcresources02_mysql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_mysql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 953.564 sec [delete] Deleting directory /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_pgsql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_pgsql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 906.979 sec [echo] Running junit test group jdbcresources02_pgsql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_pgsql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 909.106 sec {code} > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 05:26:00 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Thu, 10 Mar 2016 05:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2578 started by Daniel Simko. ------------------------------------------ > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 05:27:00 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Thu, 10 Mar 2016 05:27:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Simko resolved JBTM-2578. -------------------------------- Resolution: Done > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 05:33:01 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Thu, 10 Mar 2016 05:33:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Simko updated JBTM-2578: ------------------------------- Comment: was deleted (was: Added workaround to hudson/config_repository/scripts/eap/jbossts/narayana_tests_eap70.sh which downloads required jdbc drivers and modifies default JDBCProfile file in order to fix this job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-70-jbossts-qa-test-ipv6/ {code} junit-jdbc-ncl-testsuite: [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_oracle_thin_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_oracle_thin_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 2,999.919 sec [echo] Running junit test group jdbcresources02_oracle_thin_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_oracle_thin_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 3,046.399 sec [delete] Deleting directory /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_mysql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_mysql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 948.456 sec [echo] Running junit test group jdbcresources02_mysql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_mysql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 953.564 sec [delete] Deleting directory /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [mkdir] Created dir: /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [copy] Copying 1 file to /mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa/dbdrivers/selected_dbdriver [echo] Running junit test group jdbcresources01_pgsql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources01_pgsql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 906.979 sec [echo] Running junit test group jdbcresources02_pgsql_jndi from basedir=/mnt/hudson_workspace/workspace/eap-70-jbossts-qa-test-ipv6/qa [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_pgsql_jndi [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 909.106 sec {code}) > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 05:33:01 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Thu, 10 Mar 2016 05:33:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Simko reopened JBTM-2578: -------------------------------- > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 10:31:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 10 Mar 2016 10:31:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2638: ------------------------------------- Summary: Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper Key: JBTM-2638 URL: https://issues.jboss.org/browse/JBTM-2638 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 10:31:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 10 Mar 2016 10:31:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2638 started by Gytis Trikleris. --------------------------------------------- > Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper > --------------------------------------------------------------------------------- > > Key: JBTM-2638 > URL: https://issues.jboss.org/browse/JBTM-2638 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 10:36:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 10 Mar 2016 10:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #989 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper > --------------------------------------------------------------------------------- > > Key: JBTM-2638 > URL: https://issues.jboss.org/browse/JBTM-2638 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 10 19:05:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 10 Mar 2016 19:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2636) Backport deferred exceptions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175200#comment-13175200 ] RH Bugzilla Integration commented on JBTM-2636: ----------------------------------------------- Chao Wang changed the Status of [bug 1316270|https://bugzilla.redhat.com/show_bug.cgi?id=1316270] from NEW to MODIFIED > Backport deferred exceptions > ---------------------------- > > Key: JBTM-2636 > URL: https://issues.jboss.org/browse/JBTM-2636 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Fix For: 4.17.31 > > > Includes > * JBTM-2120 > * https://github.com/jbosstm/narayana/pull/598/commits -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:04:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2639: -------------------------------------- Summary: Setting QA_TRACE=0 does not disable trace logging in all tests Key: JBTM-2639 URL: https://issues.jboss.org/browse/JBTM-2639 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Affects Versions: 5.3.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:06:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2196: ----------------------------------- Summary: QA suite failure: CrashRecovery05_2_Test034 (was: QA suite failure: CrashRecovery05_2_Test034 & Test077) > QA suite failure: CrashRecovery05_2_Test034 > ------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test034.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/550/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:06:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2196: ----------------------------------- Attachment: (was: crashrecovery05_2_Test077.tar) > QA suite failure: CrashRecovery05_2_Test034 > ------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test034.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/550/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:08:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2196) QA suite failure: CrashRecovery05_2_Test034 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-2196. ------------------------------------ Resolution: Out of Date The hang I added to this JIRA last week was different and I have opened JBTM-2639 to track it. I am now closing this one as out of date > QA suite failure: CrashRecovery05_2_Test034 > ------------------------------------------- > > Key: JBTM-2196 > URL: https://issues.jboss.org/browse/JBTM-2196 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS, Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > Attachments: CrashRecovery05_2_Test034.tar > > > http://albany.eng.hst.ams2.redhat.com/job/narayana/550/ -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:10:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175990#comment-13175990 ] Michael Musgrove commented on JBTM-2639: ---------------------------------------- Examples of tests tjhat show excessive log output in the linked CI job are: ./txcore_lockrecord/LockRecord_Thread_Test032b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test032a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042b/client_0_output.txt ./jtatests01/JTATests01_Test006/client_0_output.txt > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 07:35:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 14 Mar 2016 07:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2639) Setting QA_TRACE=0 does not disable trace logging in all tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175990#comment-13175990 ] Michael Musgrove edited comment on JBTM-2639 at 3/14/16 7:34 AM: ----------------------------------------------------------------- Examples of tests tjhat show excessive log output in the linked CI job are: ./txcore_lockrecord/LockRecord_Thread_Test032b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test032a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042b/client_0_output.txt ./jtatests01/JTATests01_Test006/client_0_output.txt The excessive logging seems to be for similar tests. In the second ci job failure we have: find testoutput -xdev -type f -size +400M testoutput/txcore_lockrecord/LockRecord_Thread_Test032b/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test031b/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test034a/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test008a/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test031a/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test034b/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test032a/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test012b/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test035a/client_0_output.txt testoutput/txcore_lockrecord/LockRecord_Thread_Test012a/client_0_output.txt testoutput/jtatests01/JTATests01_Test006/client_0_output.txt was (Author: mmusgrov): Examples of tests tjhat show excessive log output in the linked CI job are: ./txcore_lockrecord/LockRecord_Thread_Test032b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test031a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test034b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test032a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test030b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test036b/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test033a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test035a/client_0_output.txt ./txcore_lockrecord/LockRecord_Thread_Test042b/client_0_output.txt ./jtatests01/JTATests01_Test006/client_0_output.txt > Setting QA_TRACE=0 does not disable trace logging in all tests > -------------------------------------------------------------- > > Key: JBTM-2639 > URL: https://issues.jboss.org/browse/JBTM-2639 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Occasionally some of the QA journal tests fail because of excessive logging (the job is producing over 30G of log output). I tried setting QA_TRACE=0 in the Jenkins job config but some tests are still producing trace output. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 08:49:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 08:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176066#comment-13176066 ] Gytis Trikleris commented on JBTM-2634: --------------------------------------- Quickstart is done, but cannot be merged until Spring Boot integration is released. > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 08:50:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2634 stopped by Gytis Trikleris. --------------------------------------------- > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 08:50:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2622) Implement possible new compensations api from the meeting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2622 stopped by Gytis Trikleris. --------------------------------------------- > Implement possible new compensations api from the meeting > --------------------------------------------------------- > > Key: JBTM-2622 > URL: https://issues.jboss.org/browse/JBTM-2622 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: 20160209_105648.jpg > > > Implement mock api from the meeting in order to be able to have a discussion about it on the forum. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 08:50:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2606 started by Gytis Trikleris. --------------------------------------------- > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:05:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 14 Mar 2016 09:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176080#comment-13176080 ] Tom Jenkinson commented on JBTM-2634: ------------------------------------- Can you ask for feedback on the forum now it seems complete. > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 09:25:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 09:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2634) Create Narayana Spring Boot starter quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176096#comment-13176096 ] Gytis Trikleris commented on JBTM-2634: --------------------------------------- Yes, I already have a text ready. Just waiting for one Narayana JMS PR to be reviewed. > Create Narayana Spring Boot starter quickstart > ---------------------------------------------- > > Key: JBTM-2634 > URL: https://issues.jboss.org/browse/JBTM-2634 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Demonstrator, JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Create a demonstrator application for Narayana Spring Boot starter before raising pull request to Spring. This would allow to make a better review of the Narayana Spring Boot integration on the forum. > Quickstart should have a simple example of JTA and crash recovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 10:26:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 10:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2640) Add username and password to JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2640: ------------------------------------- Summary: Add username and password to JmsXAResourceRecoveryHelper Key: JBTM-2640 URL: https://issues.jboss.org/browse/JBTM-2640 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next In some scenarios user name and password might be needed during the recovery of JMS resources. For those cases JmsXAResourceRecoveryHelper should be able to take username and password as an argument and use them when creating connections. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 10:27:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 10:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2640) Add username and password to JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2640 started by Gytis Trikleris. --------------------------------------------- > Add username and password to JmsXAResourceRecoveryHelper > -------------------------------------------------------- > > Key: JBTM-2640 > URL: https://issues.jboss.org/browse/JBTM-2640 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > In some scenarios user name and password might be needed during the recovery of JMS resources. For those cases JmsXAResourceRecoveryHelper should be able to take username and password as an argument and use them when creating connections. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 11:37:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 11:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2640) Add username and password to JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #990 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Add username and password to JmsXAResourceRecoveryHelper > -------------------------------------------------------- > > Key: JBTM-2640 > URL: https://issues.jboss.org/browse/JBTM-2640 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > In some scenarios user name and password might be needed during the recovery of JMS resources. For those cases JmsXAResourceRecoveryHelper should be able to take username and password as an argument and use them when creating connections. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 14 12:09:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Mon, 14 Mar 2016 12:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2641) Add localisation to JMS module warnings In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2641: ------------------------------------- Summary: Add localisation to JMS module warnings Key: JBTM-2641 URL: https://issues.jboss.org/browse/JBTM-2641 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next Warning messages in JMS modules should be localised same as other modules in ArjunaJTA. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 06:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 16 Mar 2016 06:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2640) Add username and password to JmsXAResourceRecoveryHelper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2640: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add username and password to JmsXAResourceRecoveryHelper > -------------------------------------------------------- > > Key: JBTM-2640 > URL: https://issues.jboss.org/browse/JBTM-2640 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > In some scenarios user name and password might be needed during the recovery of JMS resources. For those cases JmsXAResourceRecoveryHelper should be able to take username and password as an argument and use them when creating connections. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 16 07:58:00 2016 From: issues at jboss.org (Daniel Simko (JIRA)) Date: Wed, 16 Mar 2016 07:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2578) Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Simko resolved JBTM-2578. -------------------------------- Resolution: Won't Fix Fixed in our script (narayana_tests_eap70.sh). This script adjusts DB hosts to IPv6 machines in our lab. > Make "junit-jdbc-ncl-testsuite" testsuite of Narayana/qa compatible with IPv6 > ----------------------------------------------------------------------------- > > Key: JBTM-2578 > URL: https://issues.jboss.org/browse/JBTM-2578 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Hayk Hovsepyan > Assignee: Daniel Simko > Priority: Critical > > Currently JDBC tests from "junit-jdbc-ncl-testsuite" testsuite of narayana/qa tsts fail while running on pure IPv6 machine. > The reason is that it is designed to connect to databases via IPv4 protocol, and there are hostnames of DB's specified in project. > It needs to be modified to connect to databases via IPv6 addresses protocol and run tests on pure Ipv6 machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 06:20:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 18 Mar 2016 06:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2638: ---------------------------------- Summary: Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover (was: Should throw XAException instead of AssertionError in JmsXAResourceRecoveryHelper) > Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover > ------------------------------------------------------------------------------------ > > Key: JBTM-2638 > URL: https://issues.jboss.org/browse/JBTM-2638 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Mar 18 11:02:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Fri, 18 Mar 2016 11:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2638) Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2638: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Initiate connection in JmsXAResourceRecoveryHelper.getXAResources instead of recover > ------------------------------------------------------------------------------------ > > Key: JBTM-2638 > URL: https://issues.jboss.org/browse/JBTM-2638 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initially I've added assertions in JmsXAResourceRecoveryHelper to check if the recovery scan was started and delegate was initialised. However, XARecoveryModule only catches XAException, so if assertion fails periodic recovery cannot handle it. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 21 06:28:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Mar 2016 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) ArjunaJTS CosTransactions idl is not spec compliant In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2642: -------------------------------------- Summary: ArjunaJTS CosTransactions idl is not spec compliant Key: JBTM-2642 URL: https://issues.jboss.org/browse/JBTM-2642 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Reporter: Michael Musgrove Assignee: Michael Musgrove The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: {code} enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; {code} whereas we are using {code} enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusPreparing, StatusCommitting, StatusRollingBack, StatusNoTransaction }; {code} Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 21 07:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 21 Mar 2016 07:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2642: ----------------------------------- Summary: Interoperability issues with ArjunaJTS CosTransactions idl (was: ArjunaJTS CosTransactions idl is not spec compliant) > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 22 06:07:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 22 Mar 2016 06:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2606) Create Spring Boot starter for Narayana In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2606 stopped by Gytis Trikleris. --------------------------------------------- > Create Spring Boot starter for Narayana > --------------------------------------- > > Key: JBTM-2606 > URL: https://issues.jboss.org/browse/JBTM-2606 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTA > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Spring provides a bunch of Spring Boot starter artefacts in order to make integration of certain projects easier. We should investigate having one for Narayana. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 04:55:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 24 Mar 2016 04:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: Tomas Hofman created JBTM-2643: ---------------------------------- Summary: "number-of-application-rollbacks" statistic counted multiple times during single rollback Key: JBTM-2643 URL: https://issues.jboss.org/browse/JBTM-2643 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Reporter: Tomas Hofman Assignee: Tomas Hofman During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 04:56:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 24 Mar 2016 04:56:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2643 started by Tomas Hofman. ------------------------------------------ > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 05:03:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 24 Mar 2016 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181719#comment-13181719 ] Tomas Hofman commented on JBTM-2643: ------------------------------------ Two stacktraces where the value is incremented: {code} "Transaction Reaper Worker 1 at 13945" daemon prio=5 tid=0x21b nid=NA runnable java.lang.Thread.State: RUNNABLE at com.arjuna.ats.arjuna.coordinator.TxStats.incrementApplicationRollbacks(TxStats.java:263) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:120) at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:215) at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:381) at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:78) "default task-54 at 13969" prio=5 tid=0x21f nid=NA runnable java.lang.Thread.State: RUNNABLE at com.arjuna.ats.arjuna.coordinator.TxStats.incrementApplicationRollbacks(TxStats.java:263) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:120) at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.rollback(BaseTransactionManagerDelegate.java:134) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:93) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:241) 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.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.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:636) 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.as.quickstarts.ear.client.GreeterEJBLocal$$$view7.sayHello(Unknown Source:-1) at org.jboss.as.quickstarts.ear.controller.GreeterBean.sayHello(GreeterBean.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:181) at com.sun.el.parser.AstValue.invoke(AstValue.java:289) at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) at javax.faces.component.UICommand.broadcast(UICommand.java:315) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) 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:745) {code} > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 06:45:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 24 Mar 2016 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2465) PR job is missing perf regression output In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2465. ---------------------------------- Resolution: Out of Date > PR job is missing perf regression output > ---------------------------------------- > > Key: JBTM-2465 > URL: https://issues.jboss.org/browse/JBTM-2465 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.0 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.later > > > The PERF axis of the CI job https://github.com/jbosstm/narayana/pull/889 did not produce any output because of the following error: > {code} > Error: Unable to access jarfile /home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaCore/arjuna/target/benchmarks.jar > cp: cannot stat `/home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaCore/arjuna/target/jmh/com.hp.mwtests.ts.arjuna.performance.Performance1-master.csv': No such file or directory > Error: Unable to access jarfile /home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaCore/arjuna/target/benchmarks.jar > cp: cannot stat `/home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaCore/arjuna/target/jmh/com.hp.mwtests.ts.arjuna.atomicaction.CheckedActionTest-master.csv': No such file or directory > Error: Unable to access jarfile /home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaJTA/jta/target/benchmarks.jar > cp: cannot stat `/home/hudson/workspace/btny-pulls-narayana-jdk8/PROFILE/PERF/jdk/jdk8.latest/label/linux/tmp/performance/narayana/ArjunaJTA/jta/target/jmh/com.arjuna.ats.jta.xa.performance.JTAStoreTests-master.csv': No such file or directory > no benchmarks to compare > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 07:46:00 2016 From: issues at jboss.org (Anonymous (JIRA)) Date: Thu, 24 Mar 2016 07:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when TomasHofman created pull request #991 in GitHub ----------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 07:46:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 24 Mar 2016 07:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated JBTM-2643: ------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/jbosstm/narayana/pull/991 > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 24 10:22:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 24 Mar 2016 10:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #992 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Mar 28 01:33:00 2016 From: issues at jboss.org (Jive JIRA Integration (JIRA)) Date: Mon, 28 Mar 2016 01:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2624) Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jive JIRA Integration updated JBTM-2624: ---------------------------------------- Forum Reference: https://developer.jboss.org/message/953631#953631 > Introduce the administrator tool in the Narayana JTA OSGi integrated with the Karaf > ----------------------------------------------------------------------------------- > > Key: JBTM-2624 > URL: https://issues.jboss.org/browse/JBTM-2624 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > {quote} > We have several management ways in Karaf : > * mbeans (no need to rewrap them) > * shell commands > * a servlet for the felix web console (used by the community) > * a hawtio plugin (used by fuse) > The first two are the most important imho. > {quote} > the manual interventions that may be needed if the heuristic fails to rollback / commit the transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 05:02:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Write an atomic app that uses JTS and JacORB containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #160 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Write an atomic app that uses JTS and JacORB containers > ------------------------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 05:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Mar 2016 05:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-223: ------------------------------- Status: Open (was: Pull Request Sent) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 05:25:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Mar 2016 05:25:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183027#comment-13183027 ] Tom Jenkinson commented on JBTM-2642: ------------------------------------- You could create a discussion on the forum about this. [~nmcl] may have some input. > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 06:43:00 2016 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Tue, 29 Mar 2016 06:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated JBTM-2643: ------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/991, https://github.com/jbosstm/narayana/pull/993 (was: https://github.com/jbosstm/narayana/pull/991) > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 06:46:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 29 Mar 2016 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2643) "number-of-application-rollbacks" statistic counted multiple times during single rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2643: ----------------------------------- Fix Version/s: 5.next > "number-of-application-rollbacks" statistic counted multiple times during single rollback > ----------------------------------------------------------------------------------------- > > Key: JBTM-2643 > URL: https://issues.jboss.org/browse/JBTM-2643 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Fix For: 5.next > > > During transaction timeout, "number-of-application-rollbacks" stat is incremented twice. As a result, "number-of-application-rollbacks" can be higher then "number-of-aborted-transactions". -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 07:24:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 07:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2629) Implement TransactionalDriver alternative for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2629: ---------------------------------- Priority: Minor (was: Major) > Implement TransactionalDriver alternative for JMS > ------------------------------------------------- > > Key: JBTM-2629 > URL: https://issues.jboss.org/browse/JBTM-2629 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > JMS integration is done. In order to make it easier to use it in standalone Narayana, we should implement a similar utility as TransactionalDriver in JDBC. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 07:46:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 07:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2644) TM comparison job hanging In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2644: ------------------------------------- Summary: TM comparison job hanging Key: JBTM-2644 URL: https://issues.jboss.org/browse/JBTM-2644 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Gytis Trikleris Assignee: Michael Musgrove Priority: Minor {code} Exception at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) at org.objectweb.jotm.Current.commit(Current.java:452) at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745) javax.transaction.RollbackException at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) at org.objectweb.jotm.Current.commit(Current.java:452) at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745) javax.transaction.RollbackException at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) at org.objectweb.jotm.Current.commit(Current.java:452) at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745) javax.transaction.RollbackException at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) at org.objectweb.jotm.Current.commit(Current.java:452) at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745) javax.transaction.RollbackException at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) at org.objectweb.jotm.Current.commit(Current.java:452) at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) at java.util.concurrent.FutureTask.run(FutureTask.java:266) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 07:51:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 07:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2645) XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2645: ------------------------------------- Summary: XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2 failure Key: JBTM-2645 URL: https://issues.jboss.org/browse/JBTM-2645 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Reporter: Gytis Trikleris Priority: Minor {code} Running com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.636 sec <<< FAILURE! - in com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest testTimelyXAResourceRecoveryHelperRemoval2(com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest) Time elapsed: 2.616 sec <<< FAILURE! java.lang.AssertionError: helper2 removed in wrong state expected:<2> but was:<0> 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 com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval(XARecoveryModuleHelpersUnitTest.java:212) at com.hp.mwtests.ts.jta.recovery.XARecoveryModuleHelpersUnitTest.testTimelyXAResourceRecoveryHelperRemoval2(XARecoveryModuleHelpersUnitTest.java:64) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 08:01:07 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 29 Mar 2016 08:01:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2646: -------------------------------------- Summary: Include a quickstart showing a command line equivalent of the wildfly transaction console Key: JBTM-2646 URL: https://issues.jboss.org/browse/JBTM-2646 Project: JBoss Transaction Manager Issue Type: Task Components: Tooling Affects Versions: 5.3.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 08:14:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 08:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2647) Extend compensations BAControler to allow enlistment of handlers by instance In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2647: ------------------------------------- Summary: Extend compensations BAControler to allow enlistment of handlers by instance Key: JBTM-2647 URL: https://issues.jboss.org/browse/JBTM-2647 Project: JBoss Transaction Manager Issue Type: Task Components: Compensations Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 5.next Currently BAControler allows enlistment of handler only by class. It later creates instances using those classes when finishing the compensating transaction. Because of that it should be easy to allow enlisting of instances. This would allow using labdas when implementing handlers. Also instance could carry some extra information needed to compensate the transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 08:53:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 29 Mar 2016 08:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2646: ----------------------------------- Forum Reference: https://developer.jboss.org/message/953683?et=watches.email.thread#953683 > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 09:06:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 29 Mar 2016 09:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2298) Write an atomic app that uses JTS and JacORB containers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris updated JBTM-2298: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Write an atomic app that uses JTS and JacORB containers > ------------------------------------------------------- > > Key: JBTM-2298 > URL: https://issues.jboss.org/browse/JBTM-2298 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > When I created the initial docker (POC) image I did so using a standard Fedora base image. We should also look at supporting the Project Atomic docker image, since it's important for Red Hat. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 09:14:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Mar 2016 09:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2644) TM comparison job hanging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2644. ------------------------------- Resolution: Won't Fix > TM comparison job hanging > ------------------------- > > Key: JBTM-2644 > URL: https://issues.jboss.org/browse/JBTM-2644 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > > {code} > Exception > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Mar 29 09:15:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 29 Mar 2016 09:15:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2644) TM comparison job hanging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183241#comment-13183241 ] Tom Jenkinson commented on JBTM-2644: ------------------------------------- Changing job to timeout after 2 hours > TM comparison job hanging > ------------------------- > > Key: JBTM-2644 > URL: https://issues.jboss.org/browse/JBTM-2644 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > > {code} > Exception > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:745) > javax.transaction.RollbackException > at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:325) > at org.objectweb.jotm.Current.commit(Current.java:452) > at io.narayana.perf.product.ProductWorker.doWork(ProductWorker.java:51) > at io.narayana.perf.product.ProductComparison.doWork(ProductComparison.java:132) > at io.narayana.perf.product.ProductComparison.test(ProductComparison.java:87) > at io.narayana.perf.product.generated.JotmComparison_test.test_thrpt_jmhLoop(JotmComparison_test.java:127) > at io.narayana.perf.product.generated.JotmComparison_test.test_Throughput(JotmComparison_test.java:72) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:203) > at org.openjdk.jmh.runner.LoopBenchmarkHandler$BenchmarkTask.call(LoopBenchmarkHandler.java:185) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 04:36:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 30 Mar 2016 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2542: ----------------------------------- Fix Version/s: 5.next (was: 5.later) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 07:33:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Wed, 30 Mar 2016 07:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: Ond?ej Chaloupka created JBTM-2648: -------------------------------------- Summary: Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used Key: JBTM-2648 URL: https://issues.jboss.org/browse/JBTM-2648 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ond?ej Chaloupka When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 07:33:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Wed, 30 Mar 2016 07:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka updated JBTM-2648: ----------------------------------- Affects Version/s: 5.2.14.Final > Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used > ------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2648 > URL: https://issues.jboss.org/browse/JBTM-2648 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > > When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 07:34:00 2016 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Wed, 30 Mar 2016 07:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka updated JBTM-2648: ----------------------------------- Attachment: testoutput.zip TEST-org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12.txt > Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used > ------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2648 > URL: https://issues.jboss.org/browse/JBTM-2648 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Attachments: TEST-org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12.txt, testoutput.zip > > > When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 10:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 30 Mar 2016 10:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved WFLY-6443 to JBTM-2649: ------------------------------------------- Project: JBoss Transaction Manager (was: WildFly) Key: JBTM-2649 (was: WFLY-6443) Component/s: Transaction Core (was: Transactions) Target Release: (was: 7.0.0.GA) Fix Version/s: 5.next (was: 10.1.0.Final) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 10:27:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 30 Mar 2016 10:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #994 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 10:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 30 Mar 2016 10:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2649: -------------------------------- Fix Version/s: 5.2.15.Final > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.2.15.Final, 5.next > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 10:58:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 30 Mar 2016 10:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2648: ----------------------------------- Assignee: Gytis Trikleris > Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used > ------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2648 > URL: https://issues.jboss.org/browse/JBTM-2648 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: TEST-org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12.txt, testoutput.zip > > > When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Mar 30 10:58:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 30 Mar 2016 10:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2648) Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2648: -------------------------------- Fix Version/s: 5.next > Failing .Narayana qa testcase crashrecovery12 method CrashRecovery12_Test03 when journal object store is used > ------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2648 > URL: https://issues.jboss.org/browse/JBTM-2648 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.2.14.Final > Reporter: Ond?ej Chaloupka > Assignee: Gytis Trikleris > Fix For: 5.next > > Attachments: TEST-org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery12.txt, testoutput.zip > > > When using journal object store (amq) then we experience failues of test {{crashrecovery12 CrashRecovery12_Test03}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 05:47:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 31 Mar 2016 05:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2647) Extend compensations BAControler to allow enlistment of handlers by instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2647 started by Gytis Trikleris. --------------------------------------------- > Extend compensations BAControler to allow enlistment of handlers by instance > ---------------------------------------------------------------------------- > > Key: JBTM-2647 > URL: https://issues.jboss.org/browse/JBTM-2647 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Currently BAControler allows enlistment of handler only by class. It later creates instances using those classes when finishing the compensating transaction. Because of that it should be easy to allow enlisting of instances. This would allow using labdas when implementing handlers. Also instance could carry some extra information needed to compensate the transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 05:48:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 31 Mar 2016 05:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2649: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.2.15.Final, 5.next > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 06:03:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 31 Mar 2016 06:03:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2650) Remove typo from BAControler interface and its implementations In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2650: ------------------------------------- Summary: Remove typo from BAControler interface and its implementations Key: JBTM-2650 URL: https://issues.jboss.org/browse/JBTM-2650 Project: JBoss Transaction Manager Issue Type: Task Components: Compensations Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next Fix typos in BAControler, LocalBAControler, and RemoteBAControler names. Also variables when those classes are used also have typos. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 07:09:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Thu, 31 Mar 2016 07:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2647) Extend compensations BAControler to allow enlistment of handlers by instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Gytis Trikleris created pull request #996 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Extend compensations BAControler to allow enlistment of handlers by instance > ---------------------------------------------------------------------------- > > Key: JBTM-2647 > URL: https://issues.jboss.org/browse/JBTM-2647 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Currently BAControler allows enlistment of handler only by class. It later creates instances using those classes when finishing the compensating transaction. Because of that it should be easy to allow enlisting of instances. This would allow using labdas when implementing handlers. Also instance could carry some extra information needed to compensate the transaction. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 09:01:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 31 Mar 2016 09:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2649) Inconsistent behavior of journal object store for heuristic state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2649: -------------------------------------- Assignee: Tom Jenkinson (was: Michael Musgrove) > Inconsistent behavior of journal object store for heuristic state > ----------------------------------------------------------------- > > Key: JBTM-2649 > URL: https://issues.jboss.org/browse/JBTM-2649 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.15.Final, 5.next > > > We do experience inconsistent behavior of journal object store (amq) against shadow store. This starts to happen from EAP7/Narayana 5.2.14.Final. > Our test case: > *?enlist activemq JMS resource > *?enlist test XA resource > * prepare JMS resource > * prepare test XA resource > * commit JMS resource > * commit test XA resource > ** byteman force {{topLevelCommit}} to return {{XAException.XA_HEURRB}} > 2PC result for XA resource is {{TwoPhaseOutcome.HEURISTIC_HAZARD}} and client gets {{javax.transaction.HeuristicMixedException}}? > * probing log and showing state of transactions {{/subsystem=transactions/log-store=log-store:probe}} > ** expecting one indoubt participant in HEURISTIC state > * calling operation {{recovery}} on all transaction's participants > * do recovery > This works fine when Shadow log store or jdbc object store is used. For AMQ object log store the participant is first not in HEURISTIC state but is in state PREPARED. And second there is not only one participant of transaction in-doubt but they're returned two participants. > Then during recovery process the periodic recovery also can see two participants for recovery (that's my feeling from log). Not only one as expected as first resource was already correctly committed (that's how shadow log store works). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 11:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 31 Mar 2016 11:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2642: -------------------------------- Fix Version/s: 6.later > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.later > > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Mar 31 11:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 31 Mar 2016 11:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2642) Interoperability issues with ArjunaJTS CosTransactions idl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184837#comment-13184837 ] Tom Jenkinson commented on JBTM-2642: ------------------------------------- I set 6.later as it is likely a big change, we can bring it back down to 5.later if necessary with a config option. > Interoperability issues with ArjunaJTS CosTransactions idl > ---------------------------------------------------------- > > Key: JBTM-2642 > URL: https://issues.jboss.org/browse/JBTM-2642 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.later > > > The copy of CosTransactions.idl in our source tree does not match any of the OTS spec versions, in partciular the enum ordering of Status values is different so we get the wrong status when asking foreign application servers for the status of a transaction. > I checked versions 1.0 and 1.1 (http://www.omg.org/spec/OTS/) and versions 1.3 and 1.4 (http://www.omg.org/spec/TRANS/), I could not locate version 1.2. The idl used by other application servers seems to match versions 1.3 and 1.4: > {code} > enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack > }; > {code} > whereas we are using > {code} > enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, > StatusCommitted, StatusRolledBack, StatusUnknown, > StatusPreparing, StatusCommitting, StatusRollingBack, > StatusNoTransaction }; > {code} > Notice that the enum position of StatusNoTransaction is different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)