October 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3160) Start LRA returns first URI all the time

by Matej Kralik (Jira)

[ https://issues.jboss.org/browse/JBTM-3160?page=com.atlassian.jira.plugin.... ] Matej Kralik commented on JBTM-3160: ------------------------------------ Yes, I have just tested it with the latest lra-coordinator (5.10.0.Final-SNAPSHOT) and the issue is gone. Thanks > Start LRA returns first URI all the time > ---------------------------------------- > > Key: JBTM-3160 > URL: https://issues.jboss.org/browse/JBTM-3160 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Matej Kralik > Assignee: Michael Musgrove > Priority: Critical > Attachments: reporoducer-source.zip, reproducer.jar > > > The function {code:java}lraNarayanaLRAClient.startLRA(...){code} doesn't return the new URI but the URI of the first transaction all the time even though the first transaction is already closed. This happens only with coordinator 5.9.6-SNAPSHOT. For coordinator 5.9.5-Final, the function returns new URI all the time. > So when I run this code more times, the function returns the same URI all the time. In the second iteration, the URI which is returned from the startLRA() is the same as in the first iteration. That transaction is already closed so the closeLRA() failed. > {code:java} > for (int i = 0; i < 10; i++) { > URI uri = null; > uri = lraClient.startLRA(getClass().getCanonicalName() + i); > lraClient.closeLRA(uri); > } > {code} > I uploaded reproducer for it. It is spring boot application which compares returned URI from the startLRA() and the URI which is on the `http://localhost:8080/lra-coordinator` > For debugging, just import source project to IDE (I use Intelij IDEA) and run/debug _TestingApplication_. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3161: ----------------------------------- Issue Type: Feature Request (was: Bug) > Nested LRA doesn't start in the Spring Boot + JAX-RS application > ---------------------------------------------------------------- > > Key: JBTM-3161 > URL: https://issues.jboss.org/browse/JBTM-3161 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Reporter: Matej Kralik > Assignee: Michael Musgrove > Priority: Critical > Attachments: flight_5.9.6.zip, flight_5.9.8.zip, flight_5.9.8_working.zip > > > For demonstrating purpose, I migrated flight service from [narayana quickstart|https://github.com/jbosstm/quickstart/tree/master/rts/lra/flig...] to the Spring Boot application and uploaded it to the attachment. > When I stop debugger in the original swarm flight service (FlightParticipant [line 64|https://github.com/jbosstm/quickstart/blob/3b848517086c2abc32bff6895b2...]), the *_@HeaderParam(LRA_HTTP_CONTEXT_HEADER) String lraId_*, is new for that service. When I stop debugger in the SpringBoot+JAX-RS, the lraId is the same as for a parent. It looks that the _ServerLRAFilter_ doesn't start the new LRA. > I add a breakpoint to the *_ServerLRAFilter.filter(...)_* to see when the filter is applied and create new LRA before the JAX-RS method. When I call original swarm flight service, the filter is used however when I call SpringBoot flight service, the filter is not used so it looks that the filter is not used at all in the SpringBoot+JAX-RS application. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-3161: ---------------------------------------- [~mkralik] LRAParticipantRegistry is already [publicly accessible|https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-pr...]. Do you mean that the class must have an empty public constructor? > Nested LRA doesn't start in the Spring Boot + JAX-RS application > ---------------------------------------------------------------- > > Key: JBTM-3161 > URL: https://issues.jboss.org/browse/JBTM-3161 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Matej Kralik > Assignee: Michael Musgrove > Priority: Critical > Attachments: flight_5.9.6.zip, flight_5.9.8.zip, flight_5.9.8_working.zip > > > For demonstrating purpose, I migrated flight service from [narayana quickstart|https://github.com/jbosstm/quickstart/tree/master/rts/lra/flig...] to the Spring Boot application and uploaded it to the attachment. > When I stop debugger in the original swarm flight service (FlightParticipant [line 64|https://github.com/jbosstm/quickstart/blob/3b848517086c2abc32bff6895b2...]), the *_@HeaderParam(LRA_HTTP_CONTEXT_HEADER) String lraId_*, is new for that service. When I stop debugger in the SpringBoot+JAX-RS, the lraId is the same as for a parent. It looks that the _ServerLRAFilter_ doesn't start the new LRA. > I add a breakpoint to the *_ServerLRAFilter.filter(...)_* to see when the filter is applied and create new LRA before the JAX-RS method. When I call original swarm flight service, the filter is used however when I call SpringBoot flight service, the filter is not used so it looks that the filter is not used at all in the SpringBoot+JAX-RS application. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3160) Start LRA returns first URI all the time

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3160?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3160. ---------------------------------- Resolution: Cannot Reproduce I have just tested this and the reproducer works. Therefore I a closing this issue? > Start LRA returns first URI all the time > ---------------------------------------- > > Key: JBTM-3160 > URL: https://issues.jboss.org/browse/JBTM-3160 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Matej Kralik > Assignee: Michael Musgrove > Priority: Critical > Attachments: reporoducer-source.zip, reproducer.jar > > > The function {code:java}lraNarayanaLRAClient.startLRA(...){code} doesn't return the new URI but the URI of the first transaction all the time even though the first transaction is already closed. This happens only with coordinator 5.9.6-SNAPSHOT. For coordinator 5.9.5-Final, the function returns new URI all the time. > So when I run this code more times, the function returns the same URI all the time. In the second iteration, the URI which is returned from the startLRA() is the same as in the first iteration. That transaction is already closed so the closeLRA() failed. > {code:java} > for (int i = 0; i < 10; i++) { > URI uri = null; > uri = lraClient.startLRA(getClass().getCanonicalName() + i); > lraClient.closeLRA(uri); > } > {code} > I uploaded reproducer for it. It is spring boot application which compares returned URI from the startLRA() and the URI which is on the `http://localhost:8080/lra-coordinator` > For debugging, just import source project to IDE (I use Intelij IDEA) and run/debug _TestingApplication_. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3215) Rethink the system of configuration and properties with narrowing the API

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3215: -------------------------------------- Summary: Rethink the system of configuration and properties with narrowing the API Key: JBTM-3215 URL: https://issues.jboss.org/browse/JBTM-3215 Project: JBoss Transaction Manager Issue Type: Enhancement Affects Versions: 5.9.8.Final Reporter: Ondrej Chaloupka Fix For: 6.later With the growth of integrations of Narayana into various runtime, it would be good to think about the appropriateness of the configuration of Narayana via different beans and usage of reflection. The use of the reflection is especially pain point for Quarkus runtime as it decreases the startup time significantly. There is a quick fix for reflection usage as the issue JBTM-3214 and the discussion was run at the PR of the issue at https://github.com/jbosstm/narayana/pull/1521. Narrowing the API: the JBTM-3214 opens the `BeanPopulator` class create the bean class during the startup. With this change comes a possible trouble if multiple libraries tries to define the class during the startup. The one which creates and executes the bean or first one which grabs the bean defines the configuration. The following code which would try to setup the configuration will not be able to do so. Only the first setter is considered. Then possibly a single mechanism for configuration could be considered. For example we can have definition that says that all beans are for configuration from the XML (then reflection and xml parsing are done) or all beans are configurable with an external provider (no reflection and xml parsing). The `BeanPopulator` would then not having any `setter` but only `getters` (as it was until JBTM-3214) and the global configuration property will configure if reflection and XML parsing will be used or not. There is another point to consider. The Narayana configuration suffers with trouble of using `TxControl` class which is statically defined and when it's defined for the first time then change of configuration is harder. The developer needs to touch first the bean and as the second thing he needs to change the value owned by the `TxControl` class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2652) Include STM javadocs on narayana.io

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2652?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1522 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Include STM javadocs on narayana.io > ----------------------------------- > > Key: JBTM-2652 > URL: https://issues.jboss.org/browse/JBTM-2652 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation, STM > Reporter: Thomas Jenkinson > Assignee: Michael Musgrove > Priority: Major > > Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3214) Add a BeanPopulator method to directly provide a config bean

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3214?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1521 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add a BeanPopulator method to directly provide a config bean > ------------------------------------------------------------ > > Key: JBTM-3214 > URL: https://issues.jboss.org/browse/JBTM-3214 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Configuration > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Narayana has quite a flexible mechanism for setting properties: > - it uses xml property files > - it reads Java system properties > - it initialises our config beans using reflection to call the setters > Some systems, Quarkus for example, have their own config mechanisms (MicroProfile Config in the Quarkus example) so it makes sense to allow our beans to be configured directly (avoiding parsing and reflection). > Implementation wise we do already have the PropertiesFactory class to directly provide config properties but that code still uses reflection to set the actual property values and besides, it is an abstract class so we cannot safely add new methods to it. My proposal is to add a single method to the BeanPopulator class: > {code} > public static void setBeanInstance(String name, Object beanInstance) { > beanInstances.putIfAbsent(name, beanInstance); > } > {code} > This code avoids the use of reflection (and possibly xml parsing) whenever access to the named bean is required. Note that this approach requires a user to know in advance which environment beans Narayana is using. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3214) Add a BeanPopulator method to directly provide a config bean

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3214?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3214: ----------------------------------- Parent: JBTM-3209 Issue Type: Sub-task (was: Enhancement) > Add a BeanPopulator method to directly provide a config bean > ------------------------------------------------------------ > > Key: JBTM-3214 > URL: https://issues.jboss.org/browse/JBTM-3214 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Configuration > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Narayana has quite a flexible mechanism for setting properties: > - it uses xml property files > - it reads Java system properties > - it initialises our config beans using reflection to call the setters > Some systems, Quarkus for example, have their own config mechanisms (MicroProfile Config in the Quarkus example) so it makes sense to allow our beans to be configured directly (avoiding parsing and reflection). > Implementation wise we do already have the PropertiesFactory class to directly provide config properties but that code still uses reflection to set the actual property values and besides, it is an abstract class so we cannot safely add new methods to it. My proposal is to add a single method to the BeanPopulator class: > {code} > public static void setBeanInstance(String name, Object beanInstance) { > beanInstances.putIfAbsent(name, beanInstance); > } > {code} > This code avoids the use of reflection (and possibly xml parsing) whenever access to the named bean is required. Note that this approach requires a user to know in advance which environment beans Narayana is using. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3214) Add a BeanPopulator method to directly provide a config bean

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3214?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3214: ----------------------------------- Fix Version/s: 5.next (was: 5.9.8.Final) > Add a BeanPopulator method to directly provide a config bean > ------------------------------------------------------------ > > Key: JBTM-3214 > URL: https://issues.jboss.org/browse/JBTM-3214 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Configuration > Affects Versions: 5.9.8.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Narayana has quite a flexible mechanism for setting properties: > - it uses xml property files > - it reads Java system properties > - it initialises our config beans using reflection to call the setters > Some systems, Quarkus for example, have their own config mechanisms (MicroProfile Config in the Quarkus example) so it makes sense to allow our beans to be configured directly (avoiding parsing and reflection). > Implementation wise we do already have the PropertiesFactory class to directly provide config properties but that code still uses reflection to set the actual property values and besides, it is an abstract class so we cannot safely add new methods to it. My proposal is to add a single method to the BeanPopulator class: > {code} > public static void setBeanInstance(String name, Object beanInstance) { > beanInstances.putIfAbsent(name, beanInstance); > } > {code} > This code avoids the use of reflection (and possibly xml parsing) whenever access to the named bean is required. Note that this approach requires a user to know in advance which environment beans Narayana is using. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3214) Add a BeanPopulator method to directly provide a config bean

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3214: -------------------------------------- Summary: Add a BeanPopulator method to directly provide a config bean Key: JBTM-3214 URL: https://issues.jboss.org/browse/JBTM-3214 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Configuration Affects Versions: 5.9.8.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.9.8.Final Narayana has quite a flexible mechanism for setting properties: - it uses xml property files - it reads Java system properties - it initialises our config beans using reflection to call the setters Some systems, Quarkus for example, have their own config mechanisms (MicroProfile Config in the Quarkus example) so it makes sense to allow our beans to be configured directly (avoiding parsing and reflection). Implementation wise we do already have the PropertiesFactory class to directly provide config properties but that code still uses reflection to set the actual property values and besides, it is an abstract class so we cannot safely add new methods to it. My proposal is to add a single method to the BeanPopulator class: {code} public static void setBeanInstance(String name, Object beanInstance) { beanInstances.putIfAbsent(name, beanInstance); } {code} This code avoids the use of reflection (and possibly xml parsing) whenever access to the named bean is required. Note that this approach requires a user to know in advance which environment beans Narayana is using. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 October 2019