From issues at jboss.org Mon Jul 3 04:48:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Jul 2017 04:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1198 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Make the SPI a true dependency of narayana-jta pom.xml > ------------------------------------------------------ > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jul 3 04:48:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Jul 2017 04:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Summary: Make the SPI a true dependency of standalone narayana-jta pom.xml (was: Make the SPI a true dependency of narayana-jta pom.xml) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Mon Jul 3 04:48:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 3 Jul 2017 04:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Description: This means that users can simply import the narayana-jta dependency rather than both it and the SPI. It is useful when being consumed by jbpm for example. was:This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 7 11:55:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 7 Jul 2017 11:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2915) Let NarayanaJtaServletContextListener be deployed without need for web.xml change In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2915: ----------------------------------- Summary: Let NarayanaJtaServletContextListener be deployed without need for web.xml change Key: JBTM-2915 URL: https://issues.jboss.org/browse/JBTM-2915 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Currently you need a web.xml with the listener in it but if you annotate the class with javax.servlet.annotation.WebListener it will deploy automatically. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2915) Let NarayanaJtaServletContextListener be deployed without need for web.xml change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2915: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Let NarayanaJtaServletContextListener be deployed without need for web.xml change > --------------------------------------------------------------------------------- > > Key: JBTM-2915 > URL: https://issues.jboss.org/browse/JBTM-2915 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently you need a web.xml with the listener in it but if you annotate the class with javax.servlet.annotation.WebListener it will deploy automatically. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2914) Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2914: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Make sure that subordinate transactions retain knowledge of the timeout value so that they can be queried for the imported timeout value > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2914 > URL: https://issues.jboss.org/browse/JBTM-2914 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > Issue was discovered during https://issues.jboss.org/browse/JBEAP-11701 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2912: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Tom Jenkinson > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2873) WildFly to GlassFish interop: check that recovery works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2873: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > WildFly to GlassFish interop: check that recovery works > ------------------------------------------------------- > > Key: JBTM-2873 > URL: https://issues.jboss.org/browse/JBTM-2873 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS > Affects Versions: 5.5.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Check interoperability between WildFly and GlassFish. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 04:36:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.6.3.Final) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/main/java/org/jboss/narayana/rest/bridge/inbound/InboundBridgeManager.java#L60 > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9768a083ea -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:15:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2916: ----------------------------------- Summary: Disable dynamic1PC for subordinate transactions Key: JBTM-2916 URL: https://issues.jboss.org/browse/JBTM-2916 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:15:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Priority: Blocker (was: Major) > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:16:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2917) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2917: ----------------------------------- Summary: Disable dynamic1PC for subordinate transactions Key: JBTM-2917 URL: https://issues.jboss.org/browse/JBTM-2917 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.next If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:52:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.5.28.Final > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.5.28.Final, 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:53:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2916: -------------------------------- Fix Version/s: 5.2.25.Final > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.5.28.Final, 5.next > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:53:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2908: --------------------------------- > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.2.25.Final, 5.6.2.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:53:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2907: --------------------------------- > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.2.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:54:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2907: -------------------------------- Fix Version/s: 5.5.25.Final (was: 5.2.25.Final) > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.6.2.Final, 5.5.25.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:54:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2907) Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2907. ------------------------------- Resolution: Done > Implement doRecover method into JTS XATerminatorImple for WFTC inflow jca txn integration works > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2907 > URL: https://issues.jboss.org/browse/JBTM-2907 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.5.25.Final, 5.6.2.Final > > > When RAR calls {{XATerminator.recover(int)}} the call chain is not directed to Narayana implementation of XATerminator but it's passed to WFTC where {{ExtendedJBossXATerminator}} method {{doRecover}} is called. But the {{doRecover}} does not provide the expected recovery call - e.g. it does not accept flags ({{XAResource.TMSTARTRSCAN}}, {{XAResource.TMENDRSCAN}}) to drive the whole recovery process in case. > The biggest functionality trouble is for JTS where {{XATerminatorImple}} does not implement intentionally the {{doRecover}} function (https://github.com/jbosstm/narayana/blob/5.5.24.Final/ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java#L511). Thus RAR using call {{XATerminator.recover}} when JTS is under use does nothing. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:54:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2908: -------------------------------- Fix Version/s: 5.5.25.Final (was: 5.2.25.Final) > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.6.2.Final, 5.5.25.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:55:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2908) JCA committed inflow transaction is not moved to assumed completed category for JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2908. ------------------------------- Resolution: Done > JCA committed inflow transaction is not moved to assumed completed category for JTS > ----------------------------------------------------------------------------------- > > Key: JBTM-2908 > URL: https://issues.jboss.org/browse/JBTM-2908 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.2.24.Final, 5.6.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.5.25.Final, 5.6.2.Final > > > We have test which checks whether EIS is capable to finish transaction after JVM crash. > The scenario is following: > - 2 test XA resources are enlisted > - EIS RAR XATerminator calls prepare and commit > - JVM crash occurs at the start of the first XAResource.commit call > - app server is restarted > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are not rolled-back > - EIS XATerminator.commit is called > - doRecoveryScan()/waitForOrphanInterval/doRecoveryScan() > - both (mock) XAResources are committed > but the committed tx is not removed from log: > {code} > jvmCrashAfterPrepareJTS(org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase) Time elapsed: 125.532 sec <<< FAILURE! > java.lang.AssertionError: After commiting txn there should be no one in the txn log expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.jboss.as.test.jbossts.crashrec.jca.test.JcaInflowTransactionTestCase.jvmCrashAfterPrepareJTS(JcaInflowTransactionTestCase.java:763) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Fri Jul 14 06:59:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 14 Jul 2017 06:59:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2916) Disable dynamic1PC for subordinate transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2916. --------------------------------- Resolution: Done > Disable dynamic1PC for subordinate transactions > ----------------------------------------------- > > Key: JBTM-2916 > URL: https://issues.jboss.org/browse/JBTM-2916 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.2.25.Final, 5.next, 5.5.28.Final > > > If there are two resources in a BasicAction there is an optimization that will cause the second resource to commit during prepare if the first resource returns XARD_ONLY. > This can cause data inconsistency in a transaction comprising of subordinates where the phase 2 decision is rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Wed Jul 19 13:07:00 2017 From: issues at jboss.org (Anonymous (JIRA)) Date: Wed, 19 Jul 2017 13:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2680) Document compensations API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when chalda created pull request #45 in GitHub ----------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Document compensations API > -------------------------- > > Key: JBTM-2680 > URL: https://issues.jboss.org/browse/JBTM-2680 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > > There is no documentation for compensations API in our docs. Most of the things are covered in the quickstarts and blog, but adding something to the docs would be good too. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jul 20 06:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Jul 2017 06:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2918) Allow setting IsSameRMOverride as default In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2918: ----------------------------------- Summary: Allow setting IsSameRMOverride as default Key: JBTM-2918 URL: https://issues.jboss.org/browse/JBTM-2918 Project: JBoss Transaction Manager Issue Type: Component Upgrade Components: Transactional Driver Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next When transactional driver was first written the IsSameRMOverride was not required as the default but with current databases it makes a sensible default. Provide a config option to easily set this as the default. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jul 20 06:20:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Jul 2017 06:20:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2918) Allow setting IsSameRMOverride as default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2918: -------------------------------- Issue Type: Enhancement (was: Component Upgrade) > Allow setting IsSameRMOverride as default > ----------------------------------------- > > Key: JBTM-2918 > URL: https://issues.jboss.org/browse/JBTM-2918 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > When transactional driver was first written the IsSameRMOverride was not required as the default but with current databases it makes a sensible default. Provide a config option to easily set this as the default. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jul 20 06:21:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 20 Jul 2017 06:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2919) Add a default jbossts-properties.xml into the Tomcat uber jar In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2919: ----------------------------------- Summary: Add a default jbossts-properties.xml into the Tomcat uber jar Key: JBTM-2919 URL: https://issues.jboss.org/browse/JBTM-2919 Project: JBoss Transaction Manager Issue Type: Bug Components: Application Server Integration Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next There is no jbossts-properties.xml in tomcat-jta Uber jar -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Thu Jul 20 09:03:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 20 Jul 2017 09:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1488) Implement the REST-JDI specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1488: ----------------------------------- Labels: (was: student) > Implement the REST-JDI specification > ------------------------------------ > > Key: JBTM-1488 > URL: https://issues.jboss.org/browse/JBTM-1488 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: REST > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.later > > > https://community.jboss.org/wiki/CompensatingRESTfulTransactions/ -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jul 25 05:59:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 25 Jul 2017 05:59:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1965) Add support for XADisk In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1965: -------------------------------- Labels: (was: available student) > Add support for XADisk > ---------------------- > > Key: JBTM-1965 > URL: https://issues.jboss.org/browse/JBTM-1965 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 5.0.0.M5 > Reporter: Mark Little > > Transactions are often used to structure activities within reliable software applications. In Java EE, business logic typically involves accessing transactional resource managers (databases, message queues) within boundaries denoted by calls to the JTA (begin/commit/rollback). The resource managers work with the transaction manager to perform e.g. locking, logging and recovery transparently to the application programmer. However, this separation of concerns is broken with regard to one important resource: the file system. Java's file I/O library does not support transactions, a situation which requires application programmers to implement such support manually in their programs. In this project you will develop a transaction aware resource manager for file I/O in Java. This library will provide application programmers with access to a filesystem that offers ACID semantics. > We already have a transactional file I/O implementation but there are now alternatives available. XADisk (https://xadisk.java.net/) seems to have a vibrant user community, so we should take a look at this. Part of the work will be to compare and contrast the options available. > To undertake this project you should have a good understanding of Java file I/O and some knowledge of transactions (ACID semantics and the JTA). The work will be open source. -- This message was sent by Atlassian JIRA (v7.2.3#72005) From issues at jboss.org Tue Jul 25 06:16:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 25 Jul 2017 06:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2680) Document compensations API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2680: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.6.4.Final Resolution: Done > Document compensations API > -------------------------- > > Key: JBTM-2680 > URL: https://issues.jboss.org/browse/JBTM-2680 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Ondra Chaloupka > Fix For: 5.6.4.Final > > > There is no documentation for compensations API in our docs. Most of the things are covered in the quickstarts and blog, but adding something to the docs would be good too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)