January 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-860) use XAResourceWrapper metadata for assume complete

by Alon Greenland (JIRA)

[ https://issues.jboss.org/browse/JBTM-860?page=com.atlassian.jira.plugin.s... ] 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...] 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1856) Provide a transactional driver quickstart

by Alon Greenland (JIRA)

[ https://issues.jboss.org/browse/JBTM-1856?page=com.atlassian.jira.plugin.... ] Alon Greenland commented on JBTM-1856: -------------------------------------- Above links don't work anymore, here are updated links: https://github.com/jbosstm/quickstart/tree/master/transactionaldriver/tra... https://github.com/jbosstm/quickstart/tree/master/transactionaldriver/tra... > 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2983) Commit failure in WFLY LocalResource does not return error to the caller

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2983?page=com.atlassian.jira.plugin.... ] 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... > 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... > 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... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2983) Commit failure in WFLY LocalResource does not return error to the caller

by Ondra Chaloupka (JIRA)

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... 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... 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... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.... ] 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.... ] 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.... ] 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout

by Michael Musgrove (JIRA)

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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2955?page=com.atlassian.jira.plugin.... ] 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2974) Ensure that we only recover subordinate orphan Xids for servers that this server is configured for

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2974?page=com.atlassian.jira.plugin.... ] 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)

6 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2018