[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-2977.
-------------------------------
> 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
> Fix For: 5.9.0.Final
>
>
> 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, 10 months
[JBoss JIRA] (JBTM-3026) LRA tests cause issues when being built on machines/jdk preferring IPv6
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-3026?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-3026.
-------------------------------
> LRA tests cause issues when being built on machines/jdk preferring IPv6
> -----------------------------------------------------------------------
>
> Key: JBTM-3026
> URL: https://issues.jboss.org/browse/JBTM-3026
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.8.2.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Fix For: 5.9.0.Final
>
>
> There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound.
> see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}}
> {code}
> [0m[0m2018-05-23 12:07:28,018 INFO [org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final
> [0m[0m2018-05-23 12:07:28,062 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server.
> [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: java.net.SocketException: Protocol family unavailable
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:433)
> at sun.nio.ch.Net.bind(Net.java:425)
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> ... 5 more
> [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> Caused by: java.net.SocketException: Protocol family unavailable"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> [0m[0m2018-05-23 12:07:28,145 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ... 7 more
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ... 5 more
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at java.lang.reflect.Method.invoke(Method.java:498)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.Main.run(Main.java:133)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) at org.wildfly.swarm.bootstrap.Main.main(Main.java:86)
> [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.start(Swarm.java:372)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.wildfly.swarm.Swarm.main(Swarm.java:628)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ... 7 more
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener.
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at java.lang.Thread.run(Thread.java:748)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at sun.nio.ch.Net.bind0(Native Method)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at sun.nio.ch.Net.bind(Net.java:433)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at sun.nio.ch.Net.bind(Net.java:425)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245)
> [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
> [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ... 5 more
> [0m[0m2018-05-23 12:07:55,607 INFO [org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested
> [0m[0m2018-05-23 12:07:55,608 INFO [org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal
> [0m[0m2018-05-23 12:07:55,612 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping
> [0m[0m2018-05-23 12:07:55,621 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBTM-3027) Failing LRA quickstarts as Narayana still reports dependency at lra annotations
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-3027?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-3027.
-------------------------------
> Failing LRA quickstarts as Narayana still reports dependency at lra annotations
> -------------------------------------------------------------------------------
>
> Key: JBTM-3027
> URL: https://issues.jboss.org/browse/JBTM-3027
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.8.2.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Fix For: 5.9.0.Final
>
>
> LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too.
> There is fail on the injections with errors like
> {code}
> 2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient
> at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-3028?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-3028.
-------------------------------
> LRA tests can fail if the network is running slowly
> ---------------------------------------------------
>
> Key: JBTM-3028
> URL: https://issues.jboss.org/browse/JBTM-3028
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.8.2.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.9.0.Final
>
>
> SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=...) and on one of the PRs.
> [~ochaloup] did some investigation:
> {quote}
> I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch).
> Do you think you can check it on your laptop if you can see the same issue? Or how to manage that?
> Thanks
> o.
> [1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/
> [2]
> Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT
> timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 14.474 sec <<< FAILURE!
> java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0>
> at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535)
> acceptTest(io.narayana.lra.participant.SpecIT) Time elapsed: 30.335 sec <<< FAILURE!
> java.lang.AssertionError: expected:<0> but was:<2>
> at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649)
> at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624)
> connectionHangup(io.narayana.lra.participant.SpecIT) Time elapsed: 35.179 sec <<< FAILURE!
> java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6>
> at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months
[JBoss JIRA] (JBTM-3037) LRA context is not always removed if the LRA is ended
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-3037.
-------------------------------
> LRA context is not always removed if the LRA is ended
> -----------------------------------------------------
>
> Key: JBTM-3037
> URL: https://issues.jboss.org/browse/JBTM-3037
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.8.2.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.9.0.Final
>
>
> The following scenario leaves the LRA context still current:
> start an LRA
> call a service annotated with, for example,
> {code}
> @LRA(value = LRA.Type.REQUIRED, cancelOn = {Response.Status.NOT_FOUND})
> {/code}
> If the invoked method returns the NOT_FOUND status then the LRA is automatically terminated. When the request returns to the client there should be no current LRA context active. The issue here is that the next request that the client makes may still have the old LRA still associated.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 10 months