From issues at jboss.org Tue Jan 2 02:21:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 2 Jan 2018 02:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2973) Direct recoverable connection is not serialized in object store to be "directly" recoverable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2973: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Direct recoverable connection is not serialized in object store to be "directly" recoverable > -------------------------------------------------------------------------------------------- > > Key: JBTM-2973 > URL: https://issues.jboss.org/browse/JBTM-2973 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > On working with {{com.arjuna.ats.internal.jdbc.DirectRecoverableConnection}} I found out that state is not saved correctly for the connection could be restored from the object store and recovered. > The issue happens to be in case the direct recoverable {{XAResource}} throws {{XAException.XAER_RMFAIL}} on commit. That means the resource is not ready to commit but recovery should retry. In case of the {{DirectRecoverableConnection}} the state should be serialized and then restored from object store and used for recovery. > {{XAResourceRecord#prepare}} causes the connection ({{_recoveryObject}}) is saved under object store but then if fails on commit happens the {{XAResourceRecord#removeConnection}} is called where {{_recoveryObject}} is set to null and now the {{BasicAction#phase2Commit}} on call of {{updateState}} (call {{if (!save_state(state, ObjectType.ANDPERSISTENT))}}) tries to update state but the recovery object is already null and the old {{prepare}} version is overriden by {{commit}} one which has already removed information that the object is directly recoverable. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 05:13:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Jan 2018 05:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2974) Ensure that we only recover subordinate orphan Xids for servers that this server is configured for In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2974: -------------------------------- Fix Version/s: 4.17.43 5.5.31.Final > Ensure that we only recover subordinate orphan Xids for servers that this server is configured for > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2974 > URL: https://issues.jboss.org/browse/JBTM-2974 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.43, 5.5.31.Final, 5.next > > > There are two filters where we filter for subordinates but one does not check if the server is in the list of recovery nodes and one just checks to see if it matches the local server. Neither check is correct and we should see if it is in the list of XA recovery nodes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 05:13:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 15 Jan 2018 05:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2955: -------------------------------- Fix Version/s: 4.17.43 5.5.31.Final > Add a filter that checks for running subordinate transactions before identifying a branch as orphaned > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2955 > URL: https://issues.jboss.org/browse/JBTM-2955 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.43, 5.5.31.Final, 5.next > > > It is possible that when a transaction is propagated to another JVM using EJB remoting (which uses the SubordinationManager for importing a TX) and it is slow to prepare orphan detection may rollback one of its previously prepared XAResources. > We can detect if a subordinate TX is already running for a gtrid so we can use that. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 10:01:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jan 2018 10:01:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2982: -------------------------------------- Summary: LRA participant completion calls during recovery do not timeout Key: JBTM-2982 URL: https://issues.jboss.org/browse/JBTM-2982 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Michael Musgrove Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 12:02:01 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jan 2018 12:02:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2982: ----------------------------------- Component/s: LRA > LRA participant completion calls during recovery do not timeout > --------------------------------------------------------------- > > Key: JBTM-2982 > URL: https://issues.jboss.org/browse/JBTM-2982 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > > Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 12:03:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jan 2018 12:03:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2982: -------------------------------------- Assignee: Michael Musgrove > LRA participant completion calls during recovery do not timeout > --------------------------------------------------------------- > > Key: JBTM-2982 > URL: https://issues.jboss.org/browse/JBTM-2982 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 15 12:04:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 15 Jan 2018 12:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2982: ----------------------------------- Description: Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). The issue also blocks the ability to shutdown the server. was:Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). > LRA participant completion calls during recovery do not timeout > --------------------------------------------------------------- > > Key: JBTM-2982 > URL: https://issues.jboss.org/browse/JBTM-2982 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). > The issue also blocks the ability to shutdown the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 16 03:57:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 16 Jan 2018 03:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2983) Commit failure in WFLY LocalResource does not return error to the caller In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2983: ------------------------------------- Summary: Commit failure in WFLY LocalResource does not return error to the caller Key: JBTM-2983 URL: https://issues.jboss.org/browse/JBTM-2983 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Critical In case that an exception is thrown during one-phase commit of non-XA transaction participant the error is swallowed and not returned to the caller. When tested with WFLY the excpetion is shown in the log, the commit fails but the client thinks that everything worked well. The relevant part of the exception stacktrace when error on commit occurs is {code} at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1549) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.commit(LocalManagedConnection.java:96) at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:172) at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120) at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:152) at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:428) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2386) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497) {code} It seems that there is issue at https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAOnePhaseResource.java#L164 which does say something about recovery but for one phase nonXA there will be no recovery. The decision that the {{XAOnePhaseResource}} is used for the txn work is done at https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L792 where depending how the setup of {{jtaEnvironmentBean.setLastResourceOptimisationInterfaceClassName}} was done. This is done in WFLY at https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/JTAEnvironmentBeanService.java#L60 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 16 04:05:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 16 Jan 2018 04:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2983) Commit failure in WFLY LocalResource does not return error to the caller In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1271 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Commit failure in WFLY LocalResource does not return error to the caller > ------------------------------------------------------------------------ > > Key: JBTM-2983 > URL: https://issues.jboss.org/browse/JBTM-2983 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > In case that an exception is thrown during one-phase commit of non-XA transaction participant the error is swallowed and not returned to the caller. When tested with WFLY the excpetion is shown in the log, the commit fails but the client thinks that everything worked well. > The relevant part of the exception stacktrace when error on commit occurs is > {code} > at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1549) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.commit(LocalManagedConnection.java:96) > at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:172) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120) > at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:152) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:428) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2386) > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497) > {code} > It seems that there is issue at > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAOnePhaseResource.java#L164 > which does say something about recovery but for one phase nonXA there will be no recovery. > The decision that the {{XAOnePhaseResource}} is used for the txn work is done at > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L792 > where depending how the setup of {{jtaEnvironmentBean.setLastResourceOptimisationInterfaceClassName}} was done. This is done in WFLY at > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/JTAEnvironmentBeanService.java#L60 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 01:10:00 2018 From: issues at jboss.org (Alon Greenland (JIRA)) Date: Thu, 18 Jan 2018 01:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520465#comment-13520465 ] Alon Greenland commented on JBTM-1856: -------------------------------------- Above links don't work anymore, here are updated links: https://github.com/jbosstm/quickstart/tree/master/transactionaldriver/transactionaldriver-and-tomcat https://github.com/jbosstm/quickstart/tree/master/transactionaldriver/transactionaldriver-jpa-and-tomcat > Provide a transactional driver quickstart > ----------------------------------------- > > Key: JBTM-1856 > URL: https://issues.jboss.org/browse/JBTM-1856 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > > Provide a simple example of a standalone application using Narayana with Transactional Driver. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 02:57:00 2018 From: issues at jboss.org (Alon Greenland (JIRA)) Date: Thu, 18 Jan 2018 02:57:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520488#comment-13520488 ] Alon Greenland commented on JBTM-860: ------------------------------------- Hello, this issue is marked as resolved for almost 3 years now. The fix doesn't state any conditions under which it is not complete. Also, the linked Narayana team [blog post|http://jbossts.blogspot.com.au/2011/07/norecoveryxa.html] doesn't indicate any such conditions. However, in the latest EAP 7.1 [documentation|https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html-single/development_guide/index#limitations_of_the_xa_recovery_process] under "Limitations of the XA Recovery Process" for this issue it states: "JBoss EAP 7.1 has an implemented enhancement to clear transaction logs after a successfully committed transaction and the above situation should not occur frequently." It indicates that the fix doesn't fully fix the issue and that the issue can still occur under certain conditions. Any info about what these conditions are, in case this entry in the documentation is correct? > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Gytis Trikleris > Fix For: 5.1.0 > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 04:25:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 18 Jan 2018 04:25:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520537#comment-13520537 ] Ondra Chaloupka commented on JBTM-860: -------------------------------------- Hi [~alon3392], the fix of the issue is part of the JBoss EAP from release 7.0.0. I have to admit that the documentation is not clear in this and the section seems to be a remainder from times of the EAP 6.4. The core of the fix is let the transaction manager to know what is the data source of particular unfinished record in the transaction object store. That's ensured by verifying jndi name bound to the particular XAResource (loaded from the object store). The value of the jndi name is obtained from XAResources implementing the special interface https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/java/org/jboss/tm/XAResourceWrapper.java#L56. If particular implementation of the XAResource uses the wrapper and provides the jndi name identifier for the transaction manager then it's capable to decide if the indoubt transaction participant loaded from the object store was or wasn't committed. This interface is "implemented" by ironjacamar (JCA implementation in WildFly) and by Artemis ActiveMQ resource adapter. In summary it means the fix JBTM-860 involves * any datasource - database jdbc connection - configured in WildFly * artemis activemq resource adapter - {{messaging-activemq}} WildFly configuration If you use other resource adapters (e.g. WSMQ) then this fix does not apply for it. > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Gytis Trikleris > Fix For: 5.1.0 > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 05:24:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jan 2018 05:24:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520580#comment-13520580 ] Tom Jenkinson commented on JBTM-860: ------------------------------------ +1 - and would recommend a docs JBEAP issue if it is not reflected accurately in the EAP docs. Narayana is a opensource community project which is integrated into a number of containers (opensource or commercial), for example: WildFly, EAP, Spring, Karaf, Tomcat. Issues can be resolved here but still have downstream problems (in this case it seems an issue in EAP docs). Thanks for your interest in Narayana - if there is anything more we can do to help feel free to comment on issue or in our forums or IRC - there are some good links here: http://narayana.io/community/index.html > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Gytis Trikleris > Fix For: 5.1.0 > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 05:34:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 18 Jan 2018 05:34:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520586#comment-13520586 ] Tom Jenkinson commented on JBTM-860: ------------------------------------ Sorry Alon - I see you raised the discussions - they were just waiting in moderation as it must be your first post to that community I guess. Thanks again for the interest! > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Gytis Trikleris > Fix For: 5.1.0 > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 18 12:28:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 18 Jan 2018 12:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521026#comment-13521026 ] Ondra Chaloupka commented on JBTM-860: -------------------------------------- I created a documentation issue for the JBoss EAP: https://issues.jboss.org/browse/JBEAP-14113 . Feel free to add your remarks. Thank you. > use XAResourceWrapper metadata for assume complete > -------------------------------------------------- > > Key: JBTM-860 > URL: https://issues.jboss.org/browse/JBTM-860 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Resource Manager > Affects Versions: 4.15.0 > Reporter: Jonathan Halliday > Assignee: Gytis Trikleris > Fix For: 5.1.0 > > > In the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 05:06:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 05:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2984) Ensure that the JMS integration classes are in the Maven sources jar In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2984: ----------------------------------- Summary: Ensure that the JMS integration classes are in the Maven sources jar Key: JBTM-2984 URL: https://issues.jboss.org/browse/JBTM-2984 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next There is a problem that the JMS integration sources are not in the uploaded maven sources artifact. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 05:10:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 05:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2984) Ensure that the JMS integration classes are in the Maven sources jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1273 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Ensure that the JMS integration classes are in the Maven sources jar > -------------------------------------------------------------------- > > Key: JBTM-2984 > URL: https://issues.jboss.org/browse/JBTM-2984 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > There is a problem that the JMS integration sources are not in the uploaded maven sources artifact. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 05:10:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 05:10:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2984) Ensure that the JMS integration classes are in the Maven sources jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2984: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Ensure that the JMS integration classes are in the Maven sources jar > -------------------------------------------------------------------- > > Key: JBTM-2984 > URL: https://issues.jboss.org/browse/JBTM-2984 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > There is a problem that the JMS integration sources are not in the uploaded maven sources artifact. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 08:05:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 22 Jan 2018 08:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2985) Make jdbc transaction driver dynamic properties file being loaded from classpath In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2985: ------------------------------------- Summary: Make jdbc transaction driver dynamic properties file being loaded from classpath Key: JBTM-2985 URL: https://issues.jboss.org/browse/JBTM-2985 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transactional Driver Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should not be considered for micro releases or only in case it's needed for some bugfix. Consider this for {{5.8.0}} or rather for {{6.0.0}}. The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 08:06:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 22 Jan 2018 08:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2985) Make jdbc transaction driver dynamic properties file being loaded from classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2985: ---------------------------------- Description: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should not be considered for micro releases or only in case it's needed for some bugfix. The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct was: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should not be considered for micro releases or only in case it's needed for some bugfix. Consider this for {{5.8.0}} or rather for {{6.0.0}}. The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct > Make jdbc transaction driver dynamic properties file being loaded from classpath > -------------------------------------------------------------------------------- > > Key: JBTM-2985 > URL: https://issues.jboss.org/browse/JBTM-2985 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should not be considered for micro releases or only in case it's needed for some bugfix. > The fix is here > https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 > Info on using driver is here > https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 08:08:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 22 Jan 2018 08:08:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2985) Make jdbc transaction driver dynamic properties file being loaded from classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2985: ---------------------------------- Description: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at: The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct was: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should not be considered for micro releases or only in case it's needed for some bugfix. The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct > Make jdbc transaction driver dynamic properties file being loaded from classpath > -------------------------------------------------------------------------------- > > Key: JBTM-2985 > URL: https://issues.jboss.org/browse/JBTM-2985 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at: > The fix is here > https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 > Info on using driver is here > https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 08:09:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 22 Jan 2018 08:09:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2985) Make jdbc transaction driver dynamic properties file being loaded from classpath In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2985: ---------------------------------- Description: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at https://developer.jboss.org/message/979661? The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct was: It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at: The fix is here https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 Info on using driver is here https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct > Make jdbc transaction driver dynamic properties file being loaded from classpath > -------------------------------------------------------------------------------- > > Key: JBTM-2985 > URL: https://issues.jboss.org/browse/JBTM-2985 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transactional Driver > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > It would be good to add behaviour to load jdbc datasource properties file from the classpath too and not only from 'abs/relative' path. This is a change of the default behaviour and it should be considered maybe rather for some major release or if discussed at https://developer.jboss.org/message/979661? > The fix is here > https://github.com/ochaloup/narayana/commit/c383cf7fc860345b795efb5b38eeccc9f4b7cef6#diff-bd20187ffd140b809ffa8b6e38b6ec47L60 > Info on using driver is here > https://jbossts.blogspot.cz/2017/12/narayana-jdbc-transactional-driver.html#driver-direct -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2984) Ensure that the JMS integration classes are in the Maven sources jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2984. ------------------------------- > Ensure that the JMS integration classes are in the Maven sources jar > -------------------------------------------------------------------- > > Key: JBTM-2984 > URL: https://issues.jboss.org/browse/JBTM-2984 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.7.2.Final > > > There is a problem that the JMS integration sources are not in the uploaded maven sources artifact. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2974) Ensure that we only recover subordinate orphan Xids for servers that this server is configured for In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2974. ------------------------------- > Ensure that we only recover subordinate orphan Xids for servers that this server is configured for > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2974 > URL: https://issues.jboss.org/browse/JBTM-2974 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 4.17.43, 5.5.31.Final, 5.7.2.Final > > > There are two filters where we filter for subordinates but one does not check if the server is in the list of recovery nodes and one just checks to see if it matches the local server. Neither check is correct and we should see if it is in the list of XA recovery nodes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2960. ------------------------------- > STM quickstart commits an aborted action > ---------------------------------------- > > Key: JBTM-2960 > URL: https://issues.jboss.org/browse/JBTM-2960 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.2.Final > > > PCCExample STM quickstart commits an abort action and there is a typo in the attempt to compare the STM object with its clone. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2955. ------------------------------- > Add a filter that checks for running subordinate transactions before identifying a branch as orphaned > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2955 > URL: https://issues.jboss.org/browse/JBTM-2955 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.17.43, 5.5.31.Final, 5.7.2.Final > > > It is possible that when a transaction is propagated to another JVM using EJB remoting (which uses the SubordinationManager for importing a TX) and it is slow to prepare orphan detection may rollback one of its previously prepared XAResources. > We can detect if a subordinate TX is already running for a gtrid so we can use that. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2948. ------------------------------- > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2972) Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2972: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2972 > URL: https://issues.jboss.org/browse/JBTM-2972 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently the connection is pooled in that that the same connection is returned during a TX. We would like to return the connection to the pool so that it can be reused. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2968: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Some JTS quickstarts run with JacORB > ------------------------------------ > > Key: JBTM-2968 > URL: https://issues.jboss.org/browse/JBTM-2968 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are: > ArjunaJTS/pom.xml > ArjunaJTS/standalone/pom.xml > ArjunaJTS/trailmap/pom.xml -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2967: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2966) narayana-quickstarts-jts quickstart does not run standalone In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2966: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > narayana-quickstarts-jts quickstart does not run standalone > ----------------------------------------------------------- > > Key: JBTM-2966 > URL: https://issues.jboss.org/browse/JBTM-2966 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The recovery quickstart does not run due to missing maven jboss-transaction-spi dependency. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2965) Unused source directory in the quickstart repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2965: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Unused source directory in the quickstart repository > ---------------------------------------------------- > > Key: JBTM-2965 > URL: https://issues.jboss.org/browse/JBTM-2965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > There is an artifact in our quickstart repo that does not look like a quickstart and no other pom in the quickstart and performance repositories references the artifact: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTS/jta > It has never changed since the initial commit: > {quote} > commit caabc37803bac12e47f4986baca21f9052e14abc > Author: Tom Jenkinson > Date: Tue Oct 2 11:05:51 2012 +0100 > Initial version of a performance comparitor for jts and jta > {quote} > This artefact needs deleting. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2964) Clarify the build instructions in the README In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2964: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Clarify the build instructions in the README > -------------------------------------------- > > Key: JBTM-2964 > URL: https://issues.jboss.org/browse/JBTM-2964 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > There are parts of the readme that are unclear about how to build individual modules or skipping tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2963) Upgrade Artemis Journal to match version in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2963: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Upgrade Artemis Journal to match version in WildFly > --------------------------------------------------- > > Key: JBTM-2963 > URL: https://issues.jboss.org/browse/JBTM-2963 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Sync up with the version in WFLY-9345 rather than latest 2 release. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2956: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > Add a simple pooling datasource wrapper > --------------------------------------- > > Key: JBTM-2956 > URL: https://issues.jboss.org/browse/JBTM-2956 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Due to move to containerized databases we see that some of the databases can be somewhat constrained with transient connection failures. We can alleviate that slightly with a simple pooling wrapper. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) 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.7.2.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.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) 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.7.2.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.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) 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.7.2.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.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2880: -------------------------------- Fix Version/s: 5.next (was: 5.7.1.Final) (was: 5.7.2.Final) > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.next > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) 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.7.2.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.5.0#75005) From issues at jboss.org Mon Jan 22 09:47:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 09:47:01 -0500 (EST) 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.7.2.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.5.0#75005) From issues at jboss.org Mon Jan 22 10:46:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:46:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2972) Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2972: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2972 > URL: https://issues.jboss.org/browse/JBTM-2972 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently the connection is pooled in that that the same connection is returned during a TX. We would like to return the connection to the pool so that it can be reused. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2972) Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2972. ------------------------------- Assignee: Tom Jenkinson > Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2972 > URL: https://issues.jboss.org/browse/JBTM-2972 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently the connection is pooled in that that the same connection is returned during a TX. We would like to return the connection to the pool so that it can be reused. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2973) Direct recoverable connection is not serialized in object store to be "directly" recoverable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2973: -------------------------------- Fix Version/s: 5.7.2.Final > Direct recoverable connection is not serialized in object store to be "directly" recoverable > -------------------------------------------------------------------------------------------- > > Key: JBTM-2973 > URL: https://issues.jboss.org/browse/JBTM-2973 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > On working with {{com.arjuna.ats.internal.jdbc.DirectRecoverableConnection}} I found out that state is not saved correctly for the connection could be restored from the object store and recovered. > The issue happens to be in case the direct recoverable {{XAResource}} throws {{XAException.XAER_RMFAIL}} on commit. That means the resource is not ready to commit but recovery should retry. In case of the {{DirectRecoverableConnection}} the state should be serialized and then restored from object store and used for recovery. > {{XAResourceRecord#prepare}} causes the connection ({{_recoveryObject}}) is saved under object store but then if fails on commit happens the {{XAResourceRecord#removeConnection}} is called where {{_recoveryObject}} is set to null and now the {{BasicAction#phase2Commit}} on call of {{updateState}} (call {{if (!save_state(state, ObjectType.ANDPERSISTENT))}}) tries to update state but the recovery object is already null and the old {{prepare}} version is overriden by {{commit}} one which has already removed information that the object is directly recoverable. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:47:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2973) Direct recoverable connection is not serialized in object store to be "directly" recoverable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2973. ------------------------------- > Direct recoverable connection is not serialized in object store to be "directly" recoverable > -------------------------------------------------------------------------------------------- > > Key: JBTM-2973 > URL: https://issues.jboss.org/browse/JBTM-2973 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > On working with {{com.arjuna.ats.internal.jdbc.DirectRecoverableConnection}} I found out that state is not saved correctly for the connection could be restored from the object store and recovered. > The issue happens to be in case the direct recoverable {{XAResource}} throws {{XAException.XAER_RMFAIL}} on commit. That means the resource is not ready to commit but recovery should retry. In case of the {{DirectRecoverableConnection}} the state should be serialized and then restored from object store and used for recovery. > {{XAResourceRecord#prepare}} causes the connection ({{_recoveryObject}}) is saved under object store but then if fails on commit happens the {{XAResourceRecord#removeConnection}} is called where {{_recoveryObject}} is set to null and now the {{BasicAction#phase2Commit}} on call of {{updateState}} (call {{if (!save_state(state, ObjectType.ANDPERSISTENT))}}) tries to update state but the recovery object is already null and the old {{prepare}} version is overriden by {{commit}} one which has already removed information that the object is directly recoverable. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:48:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2964) Clarify the build instructions in the README In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2964. ------------------------------- Resolution: Done > Clarify the build instructions in the README > -------------------------------------------- > > Key: JBTM-2964 > URL: https://issues.jboss.org/browse/JBTM-2964 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > There are parts of the readme that are unclear about how to build individual modules or skipping tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:48:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2963) Upgrade Artemis Journal to match version in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2963. ------------------------------- Resolution: Done > Upgrade Artemis Journal to match version in WildFly > --------------------------------------------------- > > Key: JBTM-2963 > URL: https://issues.jboss.org/browse/JBTM-2963 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Sync up with the version in WFLY-9345 rather than latest 2 release. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1732: -------------------------------- Fix Version/s: 5.7.2.Final > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.7.2.Final > > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-1732. ------------------------------- > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.7.2.Final > > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2954: -------------------------------- Fix Version/s: 5.7.2.Final > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2954. ------------------------------- > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2956: -------------------------------- Fix Version/s: 5.7.2.Final (was: 5.next) > Add a simple pooling datasource wrapper > --------------------------------------- > > Key: JBTM-2956 > URL: https://issues.jboss.org/browse/JBTM-2956 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.7.2.Final > > > Due to move to containerized databases we see that some of the databases can be somewhat constrained with transient connection failures. We can alleviate that slightly with a simple pooling wrapper. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:49:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:49:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2956. ------------------------------- Resolution: Done > Add a simple pooling datasource wrapper > --------------------------------------- > > Key: JBTM-2956 > URL: https://issues.jboss.org/browse/JBTM-2956 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.7.2.Final > > > Due to move to containerized databases we see that some of the databases can be somewhat constrained with transient connection failures. We can alleviate that slightly with a simple pooling wrapper. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2951: -------------------------------- Fix Version/s: 5.7.2.Final > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2951. ------------------------------- > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2950: -------------------------------- Fix Version/s: 5.7.2.Final > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2950. ------------------------------- > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2952: -------------------------------- Fix Version/s: 5.7.2.Final > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 22 10:50:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 22 Jan 2018 10:50:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2952. ------------------------------- > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 05:07:00 2018 From: issues at jboss.org (Michal Karm Babacek (JIRA)) Date: Tue, 23 Jan 2018 05:07:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps In-Reply-To: References: Message-ID: Michal Karm Babacek created JBTM-2986: ----------------------------------------- Summary: Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps Key: JBTM-2986 URL: https://issues.jboss.org/browse/JBTM-2986 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.2.Final Environment: IBM JDK 8 Reporter: Michal Karm Babacek Assignee: Ondra Chaloupka Fix For: 5.7.2.Final I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. See [^maven.log.zip]. h3. Excerpt {noformat} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) on project lra-test: An Ant BuildException has occured: Execute failed: java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): error=2, No such file or directory [ERROR] around Ant part ...... @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml {noformat} I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 05:08:00 2018 From: issues at jboss.org (Michal Karm Babacek (JIRA)) Date: Tue, 23 Jan 2018 05:08:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Karm Babacek updated JBTM-2986: -------------------------------------- Attachment: maven.log.zip > Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2986 > URL: https://issues.jboss.org/browse/JBTM-2986 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.2.Final > Environment: IBM JDK 8 > Reporter: Michal Karm Babacek > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > Attachments: maven.log.zip > > > I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. > See [^maven.log.zip]. > h3. Excerpt > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) > on project lra-test: An Ant BuildException has occured: Execute failed: > java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" > (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): > error=2, No such file or directory > [ERROR] around Ant part ...... > @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml > {noformat} > I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. > WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 05:12:00 2018 From: issues at jboss.org (Michal Karm Babacek (JIRA)) Date: Tue, 23 Jan 2018 05:12:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Karm Babacek updated JBTM-2986: -------------------------------------- Tester: Ondrej Kotek > Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2986 > URL: https://issues.jboss.org/browse/JBTM-2986 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.2.Final > Environment: IBM JDK 8 > Reporter: Michal Karm Babacek > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > Attachments: maven.log.zip > > > I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. > See [^maven.log.zip]. > h3. Excerpt > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) > on project lra-test: An Ant BuildException has occured: Execute failed: > java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" > (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): > error=2, No such file or directory > [ERROR] around Ant part ...... > @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml > {noformat} > I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. > WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 05:52:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Jan 2018 05:52:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522365#comment-13522365 ] Ondra Chaloupka commented on JBTM-2986: --------------------------------------- the reason is that the lra integration tests uses {{post-integration-test}} in the [pom.xml|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-test/pom.xml] {{jps}} command to check running swarm container and by jps it finds out the id of process which is killed in the next {{exec}} step. I need to review way of not using {{jps}} for getting process id for this would work on IBM JDK where {{jps}} command is not provided. > Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2986 > URL: https://issues.jboss.org/browse/JBTM-2986 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.2.Final > Environment: IBM JDK 8 > Reporter: Michal Karm Babacek > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > Attachments: maven.log.zip > > > I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. > See [^maven.log.zip]. > h3. Excerpt > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) > on project lra-test: An Ant BuildException has occured: Execute failed: > java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" > (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): > error=2, No such file or directory > [ERROR] around Ant part ...... > @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml > {noformat} > I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. > WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 06:02:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 23 Jan 2018 06:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522371#comment-13522371 ] Ondra Chaloupka commented on JBTM-2986: --------------------------------------- [~mbabacek] the workaround if skipping IT tests (-Dmaven.test.skip=true) does not work as the post-integration phase is still executed even the tests theirselves are skipped. Maybe we could add a profile (https://stackoverflow.com/a/31431557/187035) for the post integration step would not be executed. > Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2986 > URL: https://issues.jboss.org/browse/JBTM-2986 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.2.Final > Environment: IBM JDK 8 > Reporter: Michal Karm Babacek > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > Attachments: maven.log.zip > > > I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. > See [^maven.log.zip]. > h3. Excerpt > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) > on project lra-test: An Ant BuildException has occured: Execute failed: > java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" > (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): > error=2, No such file or directory > [ERROR] around Ant part ...... > @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml > {noformat} > I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. > WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 07:04:00 2018 From: issues at jboss.org (Alon Greenland (JIRA)) Date: Tue, 23 Jan 2018 07:04:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2987) Treat XAER_NOTA return code as fsdfds, during rollback issued by Recovery Manager In-Reply-To: References: Message-ID: Alon Greenland created JBTM-2987: ------------------------------------ Summary: Treat XAER_NOTA return code as fsdfds, during rollback issued by Recovery Manager Key: JBTM-2987 URL: https://issues.jboss.org/browse/JBTM-2987 Project: JBoss Transaction Manager Issue Type: Task Components: JTA Affects Versions: 5.7.2.Final Reporter: Alon Greenland As discussed in https://developer.jboss.org/thread/266729, when Recovery Manager executes xaResource.rollback(xid), if it receives error code XAER_NOTA it is not really an error or warning. Currently it is logged as warning. It can be logged with debug level instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 07:05:00 2018 From: issues at jboss.org (Alon Greenland (JIRA)) Date: Tue, 23 Jan 2018 07:05:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2987) Don't treat XAER_NOTA return code as warning when doing rollback from Recovery Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alon Greenland updated JBTM-2987: --------------------------------- Summary: Don't treat XAER_NOTA return code as warning when doing rollback from Recovery Manager (was: Treat XAER_NOTA return code as fsdfds, during rollback issued by Recovery Manager) > Don't treat XAER_NOTA return code as warning when doing rollback from Recovery Manager > -------------------------------------------------------------------------------------- > > Key: JBTM-2987 > URL: https://issues.jboss.org/browse/JBTM-2987 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Affects Versions: 5.7.2.Final > Reporter: Alon Greenland > > As discussed in https://developer.jboss.org/thread/266729, when Recovery Manager executes xaResource.rollback(xid), if it receives error code XAER_NOTA it is not really an error or warning. > Currently it is logged as warning. It can be logged with debug level instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 23 10:35:00 2018 From: issues at jboss.org (Ricardo Martin Camarero (JIRA)) Date: Tue, 23 Jan 2018 10:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2928) Provide WS-AT Integration with .NET In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522564#comment-13522564 ] Ricardo Martin Camarero commented on JBTM-2928: ----------------------------------------------- When the WS-TX is initiated in the windows side, a windows client creates a context with the windows coordinator service and later it calls to a wildfly WS, the process fails at Registration operation. The JBOSS/Wildfly side tries to execute the Registration operation as a client and windows just responds 202 (no content, no XML is returned) which throws a NPE. The XML sent in the request is the following: {code:xml} http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register urn:a632e947aaf3aca5:d586ffa:15edccdf0ca:-8000 https://windows.sample.com/WsatService/Registration/Coordinator11/
http://www.w3.org/2005/08/addressing/anonymous
 edd12908-c2f4-427a-86d6-4fab6dde3d32 http://docs.oasis-open.org/ws-tx/wsat/2006/06/Durable2PC https://jboss.sample.com:8443/ws-t11-participant/ParticipantService restaurantServiceAT:f40f5b70-51c3-46f3-99c6-6052df7efa3f wsat:ParticipantService {code} After some tests it seems that windows implementation does not understand the _"http://www.w3.org/2005/08/addressing/anonymous"_ as *ReplyTo*. The request should send a *ReplyTo* with a valid URL and the Microsoft implementation calls back to that URL with the RegisterResponse type. We think that "anonymous" behavior is covered by the standard (it means synchronous execution) and that the windows implementation is an extreme interpretation of the specification (with that idea any partner, even an standalone application that calls to two web services with WS-TX support, needs to have endpoints and be a web server too). References of the ws-addressing spec about anonymous in [current|https://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#eprinfomodel] and [previous spec|https://www.w3.org/Submission/ws-addressing/#_Toc77464322]. > Provide WS-AT Integration with .NET > ----------------------------------- > > Key: JBTM-2928 > URL: https://issues.jboss.org/browse/JBTM-2928 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: J?rg B?sner > > Provide WS-AT integration for .NET -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jan 24 04:35:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 24 Jan 2018 04:35:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2983) Commit failure in WFLY LocalResource does not return error to the caller In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2983: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Commit failure in WFLY LocalResource does not return error to the caller > ------------------------------------------------------------------------ > > Key: JBTM-2983 > URL: https://issues.jboss.org/browse/JBTM-2983 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > In case that an exception is thrown during one-phase commit of non-XA transaction participant the error is swallowed and not returned to the caller. When tested with WFLY the excpetion is shown in the log, the commit fails but the client thinks that everything worked well. > The relevant part of the exception stacktrace when error on commit occurs is > {code} > at com.mysql.jdbc.ConnectionImpl.commit(ConnectionImpl.java:1549) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.commit(LocalManagedConnection.java:96) > at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:172) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120) > at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelPrepare(LastResourceRecord.java:152) > at com.arjuna.ats.arjuna.coordinator.AbstractRecord.topLevelOnePhaseCommit(AbstractRecord.java:428) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2386) > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497) > {code} > It seems that there is issue at > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAOnePhaseResource.java#L164 > which does say something about recovery but for one phase nonXA there will be no recovery. > The decision that the {{XAOnePhaseResource}} is used for the txn work is done at > https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L792 > where depending how the setup of {{jtaEnvironmentBean.setLastResourceOptimisationInterfaceClassName}} was done. This is done in WFLY at > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/JTAEnvironmentBeanService.java#L60 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jan 26 07:50:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 26 Jan 2018 07:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2988) Update activemq-artemis in the performance repo In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2988: -------------------------------------- Summary: Update activemq-artemis in the performance repo Key: JBTM-2988 URL: https://issues.jboss.org/browse/JBTM-2988 Project: JBoss Transaction Manager Issue Type: Bug Components: Performance Testing Affects Versions: 5.7.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Make sure that the artemis dependency in the performance repo matches what we use on master. So we are currently on 1.5.5.jbossorg-008 so change in the pom in our performance repo to use this version. Important: make sure that we also *replace* the native AIO library which is located in ArjunaJTA/jta/etc -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jan 27 07:02:00 2018 From: issues at jboss.org (Anonymous (JIRA)) Date: Sat, 27 Jan 2018 07:02:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2987) Don't treat XAER_NOTA return code as warning when doing rollback from Recovery Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Prim created pull request #1274 in GitHub ----------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Don't treat XAER_NOTA return code as warning when doing rollback from Recovery Manager > -------------------------------------------------------------------------------------- > > Key: JBTM-2987 > URL: https://issues.jboss.org/browse/JBTM-2987 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Affects Versions: 5.7.2.Final > Reporter: Alon Greenland > > As discussed in https://developer.jboss.org/thread/266729, when Recovery Manager executes xaResource.rollback(xid), if it receives error code XAER_NOTA it is not really an error or warning. > Currently it is logged as warning. It can be logged with debug level instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 09:30:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Mon, 29 Jan 2018 09:30:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2989) Replace to use the DBCP2 in the spring quickstarts In-Reply-To: References: Message-ID: Amos Feng created JBTM-2989: ------------------------------- Summary: Replace to use the DBCP2 in the spring quickstarts Key: JBTM-2989 URL: https://issues.jboss.org/browse/JBTM-2989 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Demonstrator Reporter: Amos Feng Assignee: Amos Feng Fix For: 5.next It could be helpful to replace the transational driver when using with the spring. The transactional driver might be only used in the standalone. -- This message was sent by Atlassian JIRA (v7.5.0#75005)