May 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3027) Failing LRA quickstarts as Narayana still reports dependency at lra annotations

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3027?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3027: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/quickstart/pull/227 > 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 > > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3027) Failing LRA quickstarts as Narayana still reports dependency at lra annotations

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3027?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3027: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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 > > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-3028?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3028: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1331 > 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.next > > > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-3028?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-3028: ---------------------------------------- The delay can result in the recovery process not being able to complete recovery of participants so the test assertions that recovery succeeded fail. The fix to the test is to retry the recovery pass a fixed number of times. Note that the delay on every packet is unreasonable and results in recovery never being able to succeed. > 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.next > > > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3028?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on JBTM-3028: --------------------------------------- I'm able to see the failing test when I run this set of commands {code} # build narayana cd rts/lra/lra-test sudo tc qdisc add dev lo root netem delay 500ms tc qdisc # (observe the rule on delaying network is set up) # [root@ochaloup ochaloup]# tc qdisc # qdisc netem 8001: dev lo root refcnt 2 limit 1000 delay 500.0ms mvn verify -Dit.test=SpecIT#acceptTest # (observe failure) # Failed tests: # SpecIT.acceptTest:624->joinAndEnd:649 expected:<0> but was:<2> sudo tc qdisc del dev lo root netem {code} > 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.next > > > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-3028: -------------------------------------- Summary: 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.next 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3025) Xid created for JTS imported transaction set up wrong node name

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3025?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3025: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Xid created for JTS imported transaction set up wrong node name > --------------------------------------------------------------- > > Key: JBTM-3025 > URL: https://issues.jboss.org/browse/JBTM-3025 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node. > I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 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.... ] Michael Musgrove updated JBTM-2978: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2979) Timeout leaves LRA active and able to complete

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2979?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2979: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Timeout leaves LRA active and able to complete > ---------------------------------------------- > > Key: JBTM-2979 > URL: https://issues.jboss.org/browse/JBTM-2979 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3025) Xid created for JTS imported transaction set up wrong node name

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-3025?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3025: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1323 > Xid created for JTS imported transaction set up wrong node name > --------------------------------------------------------------- > > Key: JBTM-3025 > URL: https://issues.jboss.org/browse/JBTM-3025 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > > For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node. > I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 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