May 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1319 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2978) Compensation should not be considered done in case of network error

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2978?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1318 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Compensation should not be considered done in case of network error > ------------------------------------------------------------------- > > Key: JBTM-2978 > URL: https://issues.jboss.org/browse/JBTM-2978 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2929) Create LRA documentation

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2929?page=com.atlassian.jira.plugin.... ] Michael Musgrove resolved JBTM-2929. ------------------------------------ Resolution: Done The documentation is maintained in the microprofile-lra repo at: [https://github.com/jbosstm/microprofile-lra/blob/microprofile-lra/spec/sr...] which in turn will be pushed to the [https://github.com/eclipse/microprofile-lra|http://example.com] repo > Create LRA documentation > ------------------------ > > Key: JBTM-2929 > URL: https://issues.jboss.org/browse/JBTM-2929 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Add LRA documentation. > The documentation is intended to be a MicroProfile specification and is available in the sandbox: https://github.com/eclipse/microprofile-sandbox/pull/2/files#diff-eeb2668... (which is part of PR https://github.com/eclipse/microprofile-sandbox/pull/2) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2959?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2959: ----------------------------------- Status: Open (was: Pull Request Sent) > Allow different LRA coordinators to share an object store > --------------------------------------------------------- > > Key: JBTM-2959 > URL: https://issues.jboss.org/browse/JBTM-2959 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. > If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Some notes on the current implementation: > # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). > # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). > # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. > # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. > # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2959?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2959: ----------------------------------- Git Pull Request: (was: https://github.com/jbosstm/narayana/pull/1317) > Allow different LRA coordinators to share an object store > --------------------------------------------------------- > > Key: JBTM-2959 > URL: https://issues.jboss.org/browse/JBTM-2959 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. > If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Some notes on the current implementation: > # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). > # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). > # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. > # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. > # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2959?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2959: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1317 > Allow different LRA coordinators to share an object store > --------------------------------------------------------- > > Key: JBTM-2959 > URL: https://issues.jboss.org/browse/JBTM-2959 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. > If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Some notes on the current implementation: > # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). > # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). > # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. > # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. > # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3018) Migrate the LRA implementation to use the microprofile-lra API

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-3018?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3018: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Migrate the LRA implementation to use the microprofile-lra API > -------------------------------------------------------------- > > Key: JBTM-3018 > URL: https://issues.jboss.org/browse/JBTM-3018 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The LRA implementation should depend on the Eclipse microprofile-lra maven artifact for the API (https://github.com/jbosstm/microprofile-lra/tree/microprofile-lra/api). > Make sure the API bundled with narayana is deprecated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2958) Wrong format of the Link header on joining LRA by participant should return error to the participant

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2958?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1317 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Wrong format of the Link header on joining LRA by participant should return error to the participant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2958 > URL: https://issues.jboss.org/browse/JBTM-2958 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If there is a participant joining a started LRA which uses wrong format of {{Link}} header then {{NullPointer}} is logged to the swarm server log. But client gets status {{OK}}. > Client should be informed that enlistment failed and there should not be nullpointer in the log. > NullPointer > {code} > INFO [io.narayana.lra] (default task-4) Cannot extract compensator from link'http://localhost': java.lang.IllegalArgumentException: RESTEASY003960: Unable to parse Link header. No end to parameter: http://localhost > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parseAttribute(LinkDelegate.java:112) > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parse(LinkDelegate.java:63) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:160) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:23) > at org.jboss.resteasy.specimpl.LinkImpl.valueOf(LinkImpl.java:31) > at org.jboss.resteasy.specimpl.LinkBuilderImpl.link(LinkBuilderImpl.java:34) > at javax.ws.rs.core.Link.valueOf(Link.java:173) > at io.narayana.lra.coordinator.domain.model.LRARecord.extractCompensator(LRARecord.java:150) > at io.narayana.lra.coordinator.domain.model.Transaction.findLRAParticipant(Transaction.java:498) > at io.narayana.lra.coordinator.domain.model.Transaction.enlistParticipant(Transaction.java:428) > at io.narayana.lra.coordinator.domain.service.LRAService.joinLRA(LRAService.java:268) > at io.narayana.lra.coordinator.domain.service.LRAService$Proxy$_$$_WeldClientProxy.joinLRA(Unknown Source) > at io.narayana.lra.coordinator.api.Coordinator.joinLRA(Coordinator.java:468) > at io.narayana.lra.coordinator.api.Coordinator.joinLRAViaBody(Coordinator.java:406) > at io.narayana.lra.coordinator.api.Coordinator$Proxy$_$$_WeldClientProxy.joinLRAViaBody(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62) > at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > The ok return code: > {code} > curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-39bdc3dc_5a098390_d > HTTP/1.1 200 OK > Connection: keep-alive > Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... > Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... > Content-Type: application/json > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2957) LRA specification: descriptions for start/end and LRA do not say which response codes are valid

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2957?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-2957. ---------------------------------- Resolution: Rejected This JIRA related to the interoperability part of the spec that defined the protocol in terms of REST endpoints and REST request/responses but interoperability has now been dropped so this JIRA is no longer applicable. Note that that the @LRA annotation controls the starting and ending of an LRA so if asynchronous operations were supported the user would just need to mark his/her resource methods with @Asynchronous. Also note that the LRAClient API start, close and cancel methods can throw GenericLRAException which exposes a getStatusCode() method for reporting HTTP status codes. > LRA specification: descriptions for start/end and LRA do not say which response codes are valid > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2957 > URL: https://issues.jboss.org/browse/JBTM-2957 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master...] are: > > Performing a `POST` on ... creates an LRA. > > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... > This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). > The proposal (and reference implementation) should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2945) Track SRAs that are started in the context of an LRA

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2945?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2945: ----------------------------------- Fix Version/s: 6.later (was: 5.later) > Track SRAs that are started in the context of an LRA > ---------------------------------------------------- > > Key: JBTM-2945 > URL: https://issues.jboss.org/browse/JBTM-2945 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 6.later > > > Often an LRA is built up from a number of individual actions performed by the > participants enlisted with the LRA. These participants may use the ACID > guarantees that an SRA provides in order to fulfil the requisite compensatory > and completion actions when the LRA is terminated. To support this requirement > when an SRA is started in the context of an LRA (either by annotating a method > with both the @LRA and @SRA annotations or by starting an SRA via the client > API when an LRA is already active) then the SRA will be automatically > associated with the LRA. The following interface is provided for querying which > LRAs and SRAs are associated with each other (in a one to many relationship): > {code} > public interface LRAToSRA { > /** > * return all the SRAs running in the context of the given LRA > */ > List<SRA> getAssociatedSRAs(URL lraId}; > /** > * see if an LRA is associated with the give SRA > */ > URL getAssociatedLRA(URL sraId); > } > {code} > Questions: > - should @Compensate and @Complete block until all associated SRAs have finished > - when an LRA is closed or cancelled should any active SRAs be automatically be committed or rolled back. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 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 2018