May 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3148) Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3148: ----------------------------------- Forum Reference: https://developer.jboss.org/message/989167#989167 (was: https://developer.jboss.org/thread/279243) > Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC > ------------------------------------------------------------------------------ > > Key: JBTM-3148 > URL: https://issues.jboss.org/browse/JBTM-3148 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. > Consider: > # first server calls a second server > # the first server uses as the resource only the remote call to the second server > # transaction context is propagated and used at the second server > # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s) > # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}} > # the second server is called with one phase commit > # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources > # prepare on database resource and JMS resource is run > # commit runs on the database resource, then... > # JVM crashes before JMS broker is committed > # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) > In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. > The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation > https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... > Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 > In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. > That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. > One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). > The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3148) Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3148: ----------------------------------- Forum Reference: https://developer.jboss.org/thread/279243 > Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC > ------------------------------------------------------------------------------ > > Key: JBTM-3148 > URL: https://issues.jboss.org/browse/JBTM-3148 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. > Consider: > # first server calls a second server > # the first server uses as the resource only the remote call to the second server > # transaction context is propagated and used at the second server > # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s) > # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}} > # the second server is called with one phase commit > # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources > # prepare on database resource and JMS resource is run > # commit runs on the database resource, then... > # JVM crashes before JMS broker is committed > # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) > In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. > The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation > https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... > Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 > In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. > That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. > One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). > The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3148) Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3148?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3148: ----------------------------------- Description: Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. Consider: # first server calls a second server # the first server uses as the resource only the remote call to the second server # transaction context is propagated and used at the second server # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s) # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}} # the second server is called with one phase commit # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources # prepare on database resource and JMS resource is run # commit runs on the database resource, then... # JVM crashes before JMS broker is committed # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. was: Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. Consider: . first server calls a second server . the first server uses as the resource only the remote call to the second server . transaction context is propagated and used at the second server . the second server makes some changes in database and sends data to JMS broker (2 XAResources) . 1PC is used to run commit on the only XAResource at the first server which is EJB remote XAResource . the second server is called with one phase commit . the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources . prepare on database resource and JMS resource is run . commit runs on the database resource, then... . JVM crashes before JMS broker is committed . (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. > Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC > ------------------------------------------------------------------------------ > > Key: JBTM-3148 > URL: https://issues.jboss.org/browse/JBTM-3148 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. > Consider: > # first server calls a second server > # the first server uses as the resource only the remote call to the second server > # transaction context is propagated and used at the second server > # the second server makes some changes in database and sends data to JMS broker (2 {{XAResource}}s) > # 1PC is used to run commit on the only XAResource at the first server which is EJB remote {{XAResource}} > # the second server is called with one phase commit > # the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources > # prepare on database resource and JMS resource is run > # commit runs on the database resource, then... > # JVM crashes before JMS broker is committed > # (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) > In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. > The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation > https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... > Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 > In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. > That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. > One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). > The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3148) Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3148: -------------------------------------- Summary: Remote JTA EJB tramsaction context propagation with fails to correctly run 1PC Key: JBTM-3148 URL: https://issues.jboss.org/browse/JBTM-3148 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.9.5.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka Remote JTA EJB transaction propagation works with the remote EJB XAResource as with any other resource which is JVM-local. As the first server uses only on participant (the remoting EJB XAResource) then the 1PC. When a failure happens at the remote side during the commit {{EJB remote XAResource.commit}} we can't define outcome. Consider: . first server calls a second server . the first server uses as the resource only the remote call to the second server . transaction context is propagated and used at the second server . the second server makes some changes in database and sends data to JMS broker (2 XAResources) . 1PC is used to run commit on the only XAResource at the first server which is EJB remote XAResource . the second server is called with one phase commit . the calls is transformed to {{SubordinateAtomicAction#doOnePhaseCommit}} which runs {{AtomicAction#End}} to call 2PC on resources . prepare on database resource and JMS resource is run . commit runs on the database resource, then... . JVM crashes before JMS broker is committed . (or JMS broker is not accessible because because of a networking issue and exception on RA commit is thrown) In case of the JVM crash heuristic outcome is saved to the object store at the first server. Administrator is expected to check what happened as the global transaction outcome is unknown. The 1PC doesn't save anything to Narayana object store. The database on the second server was committed while JMS delivery failed to commit. The picture at the [forum discussion|https://developer.jboss.org/thread/279243] depicts the situation https://developer.jboss.org/servlet/JiveServlet/showImage/2-989167-320301... Heuristic outcome for remote JTA subordinate 1PC by https://issues.jboss.org/browse/JBTM-2443 In case of the RA connection failure and in case the RA throws {{XAException.XAER_RMFAIL}} (or RETRY) - which is expected outcome when 2PC should be retried with recovery - the remote side obtains error information but 1PC only informs about error but has no record saved in the object store. Thus the transaction record is forgotten. That's not right as the JMS RA is held in prepared state. As it's part of the subordinate transaction (at the second server) it will be never finished (responsibility of finishing subordinate transaction is for the parent transaction). As the first server (the parent one) did not save any data there is nobody to finish transaction to commit. One option is to force the commit to return heuristic for administrator to finish the doubtful resource. Make it working the same way as the JVM crash scenario works (see above JBTM-2443). The other option could be not permitting the 1PC for remote JTA subordinate XAResources at all. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3146) Better support for Quarkus

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3146?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3146: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done The reviewer left an interesting note on the PR which requires following up: {quote} related: Whilst JBTM-3146 is clearly a tactical fix for Quarkus, is there a wider discussion of how default properties will work going forwards? With injection available, does it make sense to do away with the default properties file in a build in favor of injecting those defaults directly to the beans at build time? The stumbling block may be beans that exist in one module/jar but get their value from another (e.g. core configured by jta/jts) so it may lead to a messy hybrid approach that still needs files for some properties. {quote} > Better support for Quarkus > -------------------------- > > Key: JBTM-3146 > URL: https://issues.jboss.org/browse/JBTM-3146 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Common > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > To facilitate use of Narayana with containers such as Quarkus we want to minimise things like XML parsing and java archive parsing. The two main enhancements that would be useful in this respect are: > * to inject build information into a java class (via the org.jboss.maven.plugins:maven-injection-plugin plugin); > * to avoid the need for runtime parsing of XML properties it would be useful to allow the properties factory delegate to be supplied externally -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Description: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... /DurableTwoPhaseCommitParticipant.java#L232 {quote} // log an error here -- if the participant is dead it will retry anyway {quote} was: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > /DurableTwoPhaseCommitParticipant.java#L232 > {quote} > // log an error here -- if the participant is dead it will retry anyway > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Description: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... {quote} // log an error here -- if the participant is dead it will retry anyway {quote} was: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... /DurableTwoPhaseCommitParticipant.java#L232 {quote} // log an error here -- if the participant is dead it will retry anyway {quote} > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... > {quote} > // log an error here -- if the participant is dead it will retry anyway > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted but put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Description: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... was: When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} > WS-AT participant which timeouts on prepare is not aborted but put to heuristic state > ------------------------------------------------------------------------------------- > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3147?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3147: ----------------------------------- Summary: WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state (was: WS-AT participant which timeouts on prepare is not aborted but put to heuristic state) > WS-AT participant which timeouts on prepare is not aborted and cancel is not retried but both are put to heuristic state > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-3147 > URL: https://issues.jboss.org/browse/JBTM-3147 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. > This behaviour is confirmed by comments in the source code and tests expect such behaviour. > Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks > https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... > {quote} > // if prepare timed out then we return error so it goes back on the > // prepare list and is rolled back > {quote} > The same is correct for the {{cancel}} call on communication error. When cancel is called then it's expected to be retried and correct return code is needed to be returned. > See comment on the durable 2PC participant at https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSTX/classes/com... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3147) WS-AT participant which timeouts on prepare is not aborted but put to heuristic state

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3147: -------------------------------------- Summary: WS-AT participant which timeouts on prepare is not aborted but put to heuristic state Key: JBTM-3147 URL: https://issues.jboss.org/browse/JBTM-3147 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka Fix For: 5.9.5.Final When {{prepare}} on WS-AT participant timeouts (e.g. because of a communication error) such participant is marked as heuristic. That's not correct as timeouted communication during prepare is expected to be aborted. This behaviour is confirmed by comments in the source code and tests expect such behaviour. Unfortunately the returned error code makes opposite (marking participant as heuristic). The return code should do what the comment asks https://github.com/jbosstm/narayana/blob/5.9.5.Final/XTS/WSCF/classes/com... {quote} // if prepare timed out then we return error so it goes back on the // prepare list and is rolled back {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 6 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 May 2019