February 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3210) Recovery listener gets stuck with processing when unexpected exception happens

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3210?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3210: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Recovery listener gets stuck with processing when unexpected exception happens > ------------------------------------------------------------------------------ > > Key: JBTM-3210 > URL: https://issues.redhat.com/browse/JBTM-3210 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.8.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > Attachments: logs.zip > > > If the recovery is triggered with tx listener by socket call like {{SCAN}} and the recovery process itself finishes with an unexpected exception (e.g. {{IllegalStateException}}) then the listener is not informed about this happens to close and report back to user. This ends up with hanging connection and the stuck {{doRecovery}} call. > The stack trace of the {{ISE}} is like this > {code} > ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.IllegalArgumentException > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:127) > at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple.recoverTransaction(TransactionImporterImple.java:52) > at com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateAtomicActionRecoveryModule.periodicWorkFirstPass(SubordinateAtomicActionRecoveryModule.java:74) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > {code} > Stuck connection is like this > {code} > "Server.Connection:127.0.0.1:42768" #193 daemon prio=5 os_prio=0 tid=0x00007f9c20002000 nid=0x11ed8 in Object.wait() [0x00007f9dd08f8000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at java.lang.Object.wait(Object.java:502) > at com.arjuna.ats.internal.arjuna.recovery.WorkerService.doWork(WorkerService.java:101) > - locked <0x00000000d6f5ec08> (a com.arjuna.ats.internal.arjuna.recovery.WorkerService) > at com.arjuna.ats.internal.arjuna.recovery.Connection.run(Connection.java:88) > {code} > Tx listener waits forever as the connection is never flushed (https://github.com/jbosstm/narayana/blob/5.9.8.Final/txbridge/src/test/ja...) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3121) Create Quarkus LRA extension

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3121?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3121: ---------------------------------------- [~mmusgrov] is the fix version correct? > Create Quarkus LRA extension > ---------------------------- > > Key: JBTM-3121 > URL: https://issues.redhat.com/browse/JBTM-3121 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 6.later > > > Quarkus LRA extension would significantly help propagate LRA even before release. It doesn't necessarily needs to be included in the quarkus extension list until we have a stable spec version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3141) Verify that LRA logs a warning when participant status does not match the expected outcome

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3141?page=com.atlassian.jira.plugin... ] Michael Musgrove closed JBTM-3141. ---------------------------------- Resolution: Duplicate Issue This issue is now subsumed by issue JBTM-3247 > Verify that LRA logs a warning when participant status does not match the expected outcome > ------------------------------------------------------------------------------------------ > > Key: JBTM-3141 > URL: https://issues.redhat.com/browse/JBTM-3141 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If participants are unable to compensate the implementation should log a warning (and similarly for complete). Check that the implementation does this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3247: ---------------------------------------- The fix should also incorporate JBTM-3141 which I will close. > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Work on JBTM-3247 started by Michael Musgrove. ---------------------------------------------- > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3247: ---------------------------------------- I raised this as blocker since transaction failures need to be visible to the end user. > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3247) Failed LRA records are reported but they not kept

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3247?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3247: ----------------------------------- Priority: Blocker (was: Optional) > Failed LRA records are reported but they not kept > ------------------------------------------------- > > Key: JBTM-3247 > URL: https://issues.redhat.com/browse/JBTM-3247 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > When an LRA is closed/cancelled and some participants will never be able to complete/compensate then they are placed on the [BasicAction] failedList. The MP-LRA spec only requires that such failures are logged. The narayana implementation does indeed log the failure (using a log WARNING statement) but then removes the transaction record from the object store. > It would be preferable to leave failed LRA's in the store and allow them to be queried and deleted using the REST coordinator (like we do for recovering LRA's). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3121) Create Quarkus LRA extension

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3121?page=com.atlassian.jira.plugin... ] Michael Musgrove resolved JBTM-3121. ------------------------------------ Release Notes Text: The PR for this was raised some time ago (https://github.com/quarkusio/quarkus/pull/6763) but new extensions are being deferred until 1.3.0 is ready (end of Feb) Resolution: Done > Create Quarkus LRA extension > ---------------------------- > > Key: JBTM-3121 > URL: https://issues.redhat.com/browse/JBTM-3121 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 6.later > > > Quarkus LRA extension would significantly help propagate LRA even before release. It doesn't necessarily needs to be included in the quarkus extension list until we have a stable spec version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3223) Validate LRA behaviour when multiple LRA's are active on the same thread

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3223?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3223: ----------------------------------- Priority: Blocker (was: Major) > Validate LRA behaviour when multiple LRA's are active on the same thread > ------------------------------------------------------------------------- > > Key: JBTM-3223 > URL: https://issues.redhat.com/browse/JBTM-3223 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.10.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > Add tests that check that when multiple LRA's are active on the same thread that as one LRA finishes that: > - the next one is handled correctly > - creating another one still works fine > This issues relates to some suspect code at the end of the method `NarayanaLRAClient#endLRA` where the base URI of the target coordinator includes the Uid part of the LRA id. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3228) Nested LRA participants should have Forget methods called when the parent LRA is closed

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3228?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3228: ----------------------------------- Priority: Blocker (was: Major) > Nested LRA participants should have Forget methods called when the parent LRA is closed > --------------------------------------------------------------------------------------- > > Key: JBTM-3228 > URL: https://issues.redhat.com/browse/JBTM-3228 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Blocker > > https://github.com/eclipse/microprofile-lra/issues/208 > According to the specification, we should call Forget on nested LRA participants when the parent LRA is closed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 2 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 February 2020