October 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3213) Ensure the LRA module is configurable

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3213: -------------------------------------- Summary: Ensure the LRA module is configurable Key: JBTM-3213 URL: https://issues.jboss.org/browse/JBTM-3213 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.9.8.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next There are some LRA parameters that we would like to be configurable (timeouts and thread pools for example). Since LRA is a microprofile spec we should leverage microprofile-config for this purpose. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3212) Ensure that an LRA timeout timer is restarted after a crash

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3212?page=com.atlassian.jira.plugin.... ] Work on JBTM-3212 started by Michael Musgrove. ---------------------------------------------- > Ensure that an LRA timeout timer is restarted after a crash > ----------------------------------------------------------- > > Key: JBTM-3212 > URL: https://issues.jboss.org/browse/JBTM-3212 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > LRAs can be timed out. After a crash the time should be restarted. Currently this functionality is marked as a TODO item: > > https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... > and > https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3211) Re-enable lra-test-basic

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3211?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3211: ----------------------------------- Priority: Blocker (was: Major) > Re-enable lra-test-basic > ------------------------ > > Key: JBTM-3211 > URL: https://issues.jboss.org/browse/JBTM-3211 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.next > > > This [particular test|https://github.com/jbosstm/narayana/tree/master/rts/lra/lra-test/lra...] is for the Narayana specific LRA client which was temporarily disabled during PR 1515. It needs to be re-enabled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3212) Ensure that an LRA timeout timer is restarted after a crash

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3212: -------------------------------------- Summary: Ensure that an LRA timeout timer is restarted after a crash Key: JBTM-3212 URL: https://issues.jboss.org/browse/JBTM-3212 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.8.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next LRAs can be timed out. After a crash the time should be restarted. Currently this functionality is marked as a TODO item: https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... and https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3209) Using JTA with Quarkus: measure and improve memory utilisation and startup time

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3209?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3209: ----------------------------------- Description: The JTA TM runs well on application servers where applications typically run for extended periods of time giving plenty of scope for the JIT compiler to optimise the bytecode. Frameworks like Quarkus are particularly well suited to running short duration applications due to the faster startup times and often lower resource footprint but they can miss out on the benefits that JIT provides. This task is to check whether or not there are opportunites to improve startup time (and resource usage). If/when such changes are identified please raise a linked JIRA so that we can track any specific changes. was: Applications that consume the quarkus-narayana-jta extension incur a significant resource footprint because things like: - Lots of reflection going on. - TransactionManagerStatus is initialised during build (can't be reconfigured - moving it to "part runtime" needs some work) - It's still logging that ports are being opened during native-image (this confuses people during presentations as we say that's impossible) This list is not exhaustive and the task is to investigate where we can improve things > Using JTA with Quarkus: measure and improve memory utilisation and startup time > ------------------------------------------------------------------------------- > > Key: JBTM-3209 > URL: https://issues.jboss.org/browse/JBTM-3209 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > > The JTA TM runs well on application servers where applications typically run for extended periods of time giving plenty of scope for the JIT compiler to optimise the bytecode. Frameworks like Quarkus are particularly well suited to running short duration applications due to the faster startup times and often lower resource footprint but they can miss out on the benefits that JIT provides. > This task is to check whether or not there are opportunites to improve startup time (and resource usage). If/when such changes are identified please raise a linked JIRA so that we can track any specific changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3209) Using JTA with Quarkus: measure and improve memory utilisation and startup time

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3209?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3209: ----------------------------------- Summary: Using JTA with Quarkus: measure and improve memory utilisation and startup time (was: Reduce the JTA resource footprint when used with Quarkus) > Using JTA with Quarkus: measure and improve memory utilisation and startup time > ------------------------------------------------------------------------------- > > Key: JBTM-3209 > URL: https://issues.jboss.org/browse/JBTM-3209 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > > Applications that consume the quarkus-narayana-jta extension incur a significant resource footprint because things like: > - Lots of reflection going on. > - TransactionManagerStatus is initialised during build (can't be reconfigured - moving it to "part runtime" needs some work) > - It's still logging that ports are being opened during native-image (this confuses people during presentations as we say that's impossible) > This list is not exhaustive and the task is to investigate where we can improve things -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3211) Re-enable lra-test-basic

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3211: -------------------------------------- Summary: Re-enable lra-test-basic Key: JBTM-3211 URL: https://issues.jboss.org/browse/JBTM-3211 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.8.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next This [particular test|https://github.com/jbosstm/narayana/tree/master/rts/lra/lra-test/lra...] is for the Narayana specific LRA client which was temporarily disabled during PR 1515. It needs to be re-enabled. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3189) Resteasy providers are absent when a thread from the ForkJoinPool is used to cancel the LRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3189?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1515 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Resteasy providers are absent when a thread from the ForkJoinPool is used to cancel the LRA > ------------------------------------------------------------------------------------------- > > Key: JBTM-3189 > URL: https://issues.jboss.org/browse/JBTM-3189 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > When an LRA is cancelled from a timer the cancellation is performed by a thread from the ForkJoinPool. None of the Resteasy JAX-RS providers are available on this thread. Outgoing JAX-RS calls made from this thread will then fail. > Since the LRA coordinator only uses REST calls it would be better to use something like java.net.HttpURLConnection or wait for java.net.http.HttpClient which is in JDK 11. > But as an interim fix I would suggest that the timeout handler sets the status to Cancelling and then when the LRA is later closed we check whether the timer triggered and cancel the LRA. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 11 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3210?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondrej Chaloupka created pull request #1514 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Recovery listener gets stuck with processing when unexpected exception happens > ------------------------------------------------------------------------------ > > Key: JBTM-3210 > URL: https://issues.jboss.org/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, 11 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3210?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3210: ----------------------------------- Attachment: logs.zip > Recovery listener gets stuck with processing when unexpected exception happens > ------------------------------------------------------------------------------ > > Key: JBTM-3210 > URL: https://issues.jboss.org/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, 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 October 2019