December 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3086) dependentLRA test failure

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3086: -------------------------------------- Summary: dependentLRA test failure Key: JBTM-3086 URL: https://issues.jboss.org/browse/JBTM-3086 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/...] in the microprofile-lra test suite fails if [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/sr...] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3086) dependentLRA test failure

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3086?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3086: ----------------------------------- Description: The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/...] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/sr...] is set to true. (was: The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/...] in the microprofile-lra test suite fails if [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/sr...] is set to true.) > dependentLRA test failure > ------------------------- > > Key: JBTM-3086 > URL: https://issues.jboss.org/browse/JBTM-3086 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The TCK test [dependentLRA|https://github.com/eclipse/microprofile-lra/blob/master/tck/...] in the microprofile-lra test suite fails if the [terminal attribute of the LRA annotation|https://github.com/eclipse/microprofile-lra/blob/master/api/sr...] is set to true. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-3034. ------------------------------- Resolution: Done > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.0.Final, 5.5.33.Final > > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3034: -------------------------------- Fix Version/s: 5.5.33.Final > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.5.33.Final, 5.9.0.Final > > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-3034: --------------------------------- > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.5.33.Final, 5.9.0.Final > > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3079) InboundBridge recovery aborts live transactions

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3079?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3079: -------------------------------- Fix Version/s: 5.next 5.5.34.Final > InboundBridge recovery aborts live transactions > ----------------------------------------------- > > Key: JBTM-3079 > URL: https://issues.jboss.org/browse/JBTM-3079 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.32.Final, 5.9.0.Final > Environment: EAP 7.1.5 / 5.5.32.Final > Reporter: Jonathan Halliday > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.5.34.Final, 5.next > > Attachments: jbtm3079.patch > > > During a recovery pass, the InboundBridgeRecoveryManager scans for subordinate XA branches that may need cleanup. The filtering process applied by checkXid correctly excludes tx that are not owned by the bridge, but fails to ignore those that are owned but also still live. Therefore, a race condition exists such that the recovery process may incorrectly abort a branch if invoked between the prepare and commit steps, resulting in data corruption relative to other committed branches from the parent i.e. Heuristic outcomes. > TRACE [org.jboss.jbossts.txbridge] (TaskWorker-3) BridgeDurableParticipant.prepare(Xid=< 131080, 35, 64, ... >) > TRACE [org.jboss.jbossts.txbridge] (Periodic Recovery) rolling back orphaned subordinate tx < 131080, 35, 64, ... > > ERROR [org.jboss.jbossts.txbridge] (TaskWorker-8) ARJUNA033004: commit on Xid=< 131080, 35, 64, ... > failed: javax.transaction.xa.XAException > It is necessary to enhance checkXid to validate against known live tx. The easiest way would seem to be to have the InboundBridgeManager singleton hold a lookup table of live tx, effectively a secondary index into its existing collection of InboundBridges, against which the recovery system can validate the in-doubt Xid. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3085) Compensations test fail because of WildFly module changes

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3085?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3085: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Compensations test fail because of WildFly module changes > --------------------------------------------------------- > > Key: JBTM-3085 > URL: https://issues.jboss.org/browse/JBTM-3085 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Affects Versions: 5.9.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > There was change in module dependencies for compensations (see at https://issues.jboss.org/browse/WFLY-11421) which requires changes into testsuite of compensations. > Currently the narayana CI XTS tests are failing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3085) Compensations test fail because of WildFly module changes

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3085?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1392 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Compensations test fail because of WildFly module changes > --------------------------------------------------------- > > Key: JBTM-3085 > URL: https://issues.jboss.org/browse/JBTM-3085 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Affects Versions: 5.9.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > There was change in module dependencies for compensations (see at https://issues.jboss.org/browse/WFLY-11421) which requires changes into testsuite of compensations. > Currently the narayana CI XTS tests are failing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2967: -------------------------------- Fix Version/s: 5.next (was: 5.9.1.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.9.1.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Major > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef209... > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef209... -- This message was sent by Atlassian Jira (v7.12.1#712002)

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