October 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2936?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2936. ------------------------------- > JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id > ------------------------------------------------------------------------------------ > > Key: JBTM-2936 > URL: https://issues.jboss.org/browse/JBTM-2936 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2935) Make LRA @Complete optional

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2935?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2935. ------------------------------- > Make LRA @Complete optional > --------------------------- > > Key: JBTM-2935 > URL: https://issues.jboss.org/browse/JBTM-2935 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > LRA compensators currently require both @Complete and @Compensate annotations to be present. The @Complete should be optional. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2940) LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2940?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2940. ------------------------------- > LRA participant complete/compensate endpoints should be allowed to return a 202 Accepted HTTP status > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2940 > URL: https://issues.jboss.org/browse/JBTM-2940 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The compensate and complete participant endpoints are allowed to return `202 Accepted` if they cannot complete the operation immediately in which case they should either return a status URL in the HTTP Location Header of the response or the resource class should contain a method annotated with @Status. > Recovery should then periodically probe the status and clean up once the status indicates that the participant has completed or compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2939. ------------------------------- > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.1.Final > > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2937) Do not recommend "X-" prefixed headers

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2937?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2937. ------------------------------- > Do not recommend "X-" prefixed headers > -------------------------------------- > > Key: JBTM-2937 > URL: https://issues.jboss.org/browse/JBTM-2937 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > Quote from PR https://github.com/jbosstm/microprofile-sandbox/pull/3 raised by @nicolaferraro : > {quote} > A small change to the spec in order to use "Long-Running-Action" and "Short-Running-Action" headers instead of "X-lra" and "X-sra". > "X-" prefixed headers should be deprecated by RFC-6648 and RFC-7231. > They are not mandated by this spec, but they'll be used by microprofile rest services, so it's important for other technologies to use them if they want to build interoperable rest services. > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2947) LRA client API is still using the old spec

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2947?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2947. ------------------------------- > LRA client API is still using the old spec > ------------------------------------------ > > Key: JBTM-2947 > URL: https://issues.jboss.org/browse/JBTM-2947 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The LRA end call in the client API is still expecting the response to contain are array of strings returned by each participant during the termination phase. The spec has since been updated and instead just the current status of the LRA is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2946) LRA quickstart is not spec compliant

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2946?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2946. ------------------------------- > LRA quickstart is not spec compliant > ------------------------------------ > > Key: JBTM-2946 > URL: https://issues.jboss.org/browse/JBTM-2946 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The quickstart interprets the return value from an LRA close call to comprise the business data returned from each participant complete call (as a json array). The spec has since been updated for the LRA close operation to not return business data (since it is considered an anti-pattern in some circles). > The quickstart should revert to an earlier version where the outcome of the "sub bookings" was obtained by querying the services directly (it should still be in the commit history). > In particular look at the code TripCheck.java in commit e2514c4bb3e2b80f0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2941) Support JAX-RS unaware LRA participants

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2941?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2941. ------------------------------- > Support JAX-RS unaware LRA participants > --------------------------------------- > > Key: JBTM-2941 > URL: https://issues.jboss.org/browse/JBTM-2941 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The LRA proposal includes a Java based compensation registration API to support those applications that cannot directly expose JAX-RS endpoints for compensation activities. This JIRA adds a reference implementation of that API. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2944) LRA specification updates

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2944. ------------------------------- > LRA specification updates > ------------------------- > > Key: JBTM-2944 > URL: https://issues.jboss.org/browse/JBTM-2944 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.1.Final > > > The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox): > 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants. > 2. Terminating an LRA MAY return the status of the LRA. > 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes. > 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in. > > 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body. > 6. Remove the interface method for starting an LRA > {code} > URL startLRA(String clientID, Long timeout) throws GenericLRAException; > {code} > since it is superfluous - just use the one that takes a timeunit instead: > {code} > URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2948: ------------------------------------- Summary: 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 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@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@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)

6 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 October 2017