October 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3190) Transform LRA coordinator runtime to Quarkus

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3190?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3190: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Transform LRA coordinator runtime to Quarkus > -------------------------------------------- > > Key: JBTM-3190 > URL: https://issues.jboss.org/browse/JBTM-3190 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.8.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > [LRA coordinator|https://github.com/jbosstm/narayana/tree/master/rts/lra/lra-c...] is an essential part of Narayana LRA processing. It would be beneficial to move the runtime from [Thorntail|https://thorntail.io] to [Quarkus|https://quarkus.io] for faster startup times and better memory utilization. > If possible, one additional step can be to compile lra-coordinator to the native executable which can bump out the performance of the lra-coordinator docker image. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3207) The LRA coordinator no longer runs on thorntail

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3207?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3207: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > The LRA coordinator no longer runs on thorntail > ----------------------------------------------- > > Key: JBTM-3207 > URL: https://issues.jboss.org/browse/JBTM-3207 > 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 > > > Some recent changes to the LRA build mean that we can no longer run it on thorntail. > The fix is to separate out the coordinator source files into a separate jar and have the different runtimes consume it and add any required dependencies required for that runtime. > In particular there are LRA quickstarts that run with thorntail no longer run. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3207) The LRA coordinator no longer runs on thorntail

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3207?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1511 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > The LRA coordinator no longer runs on thorntail > ----------------------------------------------- > > Key: JBTM-3207 > URL: https://issues.jboss.org/browse/JBTM-3207 > 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 > > > Some recent changes to the LRA build mean that we can no longer run it on thorntail. > The fix is to separate out the coordinator source files into a separate jar and have the different runtimes consume it and add any required dependencies required for that runtime. > In particular there are LRA quickstarts that run with thorntail no longer run. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3207) The LRA coordinator no longer runs on thorntail

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3207: -------------------------------------- Summary: The LRA coordinator no longer runs on thorntail Key: JBTM-3207 URL: https://issues.jboss.org/browse/JBTM-3207 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 Some recent changes to the LRA build mean that we can no longer run it on thorntail. The fix is to separate out the coordinator source files into a separate jar and have the different runtimes consume it and add any required dependencies required for that runtime. In particular there are LRA quickstarts that run with thorntail no longer run. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3203) Align XTS SSL quickstart to use the WFLY18 bom when released

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3203?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3203: ----------------------------------- Summary: Align XTS SSL quickstart to use the WFLY18 bom when released (was: Allign XTS SSL quickstart to use the WFLY18 bom when released) > Align XTS SSL quickstart to use the WFLY18 bom when released > ------------------------------------------------------------ > > Key: JBTM-3203 > URL: https://issues.jboss.org/browse/JBTM-3203 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The XTS over SSL fails with dependency issue {{'dependencies.dependency.version' for jakarta.enterprise:jakarta.enterprise.cdi-api:jar is missing. @ org.wildfly.quickstarts:wsat-simple:[unknown-version]}}[1]. > The trouble is that the test runs with the most recent {{wildfly/quickstart}} repo and consumes the bom from WFLY17. There is not defined the {{jakarta}} dependencies yet. We need to wait for WFLY18 bom with {{jakarta}} dependencies is released and then the test setup has to be fixed. > [1] > {code} > [ERROR] 'dependencies.dependency.version' for jakarta.enterprise:jakarta.enterprise.cdi-api:jar is missing. @ org.wildfly.quickstarts:wsat-simple:[unknown-version], /home/jenkins/workspace/narayana-quickstarts/quickstart/wsat-simple/pom.xml, line 48, column 21 > at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:416) > at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:672) > at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:663) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:253) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [ERROR] > [ERROR] The project org.wildfly.quickstarts:wsat-simple:18.0.0.Final-SNAPSHOT (/home/jenkins/workspace/narayana-quickstarts/quickstart/wsat-simple/pom.xml) has 1 error > [ERROR] 'dependencies.dependency.version' for jakarta.enterprise:jakarta.enterprise.cdi-api:jar is missing. @ org.wildfly.quickstarts:wsat-simple:[unknown-version], /home/jenkins/workspace/narayana-quickstarts/quickstart/wsat-simple/pom.xml, line 48, column 21 > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3193) RTS benchmarks do not run

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3193?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Thomas Jenkinson created pull request #61 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > RTS benchmarks do not run > ------------------------- > > Key: JBTM-3193 > URL: https://issues.jboss.org/browse/JBTM-3193 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > > There looks to be a JTA record in the object store when they are run. Could it be from a previous run? Or is it expected and if so why is the RecordManager unaware of the JTA_RECORD type for this run due to https://github.com/jbosstm/narayana/blob/1e17caa16b5efb9b16cdb2d8489a1b93... not being triggered? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3193) RTS benchmarks do not run

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3193?page=com.atlassian.jira.plugin.... ] Work on JBTM-3193 stopped by Thomas Jenkinson. ---------------------------------------------- > RTS benchmarks do not run > ------------------------- > > Key: JBTM-3193 > URL: https://issues.jboss.org/browse/JBTM-3193 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > > There looks to be a JTA record in the object store when they are run. Could it be from a previous run? Or is it expected and if so why is the RecordManager unaware of the JTA_RECORD type for this run due to https://github.com/jbosstm/narayana/blob/1e17caa16b5efb9b16cdb2d8489a1b93... not being triggered? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3193) RTS benchmarks do not run

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3193?page=com.atlassian.jira.plugin.... ] Work on JBTM-3193 started by Thomas Jenkinson. ---------------------------------------------- > RTS benchmarks do not run > ------------------------- > > Key: JBTM-3193 > URL: https://issues.jboss.org/browse/JBTM-3193 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > > There looks to be a JTA record in the object store when they are run. Could it be from a previous run? Or is it expected and if so why is the RecordManager unaware of the JTA_RECORD type for this run due to https://github.com/jbosstm/narayana/blob/1e17caa16b5efb9b16cdb2d8489a1b93... not being triggered? -- 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 Matej Kralik (Jira)

[ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.... ] Matej Kralik edited comment on JBTM-3161 at 10/3/19 4:40 AM: ------------------------------------------------------------- When I added the missing _LRAParticipantRegistry_ dependency to the application _JerseyConfig_, the application work* with the latest Narayana as well. Example of Jersey Config.: {code:java} @Component @ApplicationPath("/") public class JerseyConfig extends ResourceConfig { public JerseyConfig() throws URISyntaxException { register(WadlResource.class); register(FlightParticipant.class); packages("io.narayana.lra.filter"); register(new AbstractBinder(){ @Override protected void configure() { bind(LRAParticipantRegistry.class) .to(LRAParticipantRegistry.class); } }); } } {code} \* However, the LRAParticipantRegistry has to be public. [~mmusgrov] Is it possible to make the LRAParticipantRegistry public in the implementation? Once it will be public, I can create an example of how to use LRA in the Spring Boot + JAX-RS(jersey) service to the Narayana lra quickstart (flight_5.9.8_working in Attachments). was (Author: mkralik): When I added the missing _LRAParticipantRegistry_ dependency to the application _JerseyConfig_, the application work* with the latest Narayana as well. Example of Jersey Config.: {code:java} @Component @ApplicationPath("/") public class JerseyConfig extends ResourceConfig { public JerseyConfig() throws URISyntaxException { register(WadlResource.class); register(FlightParticipant.class); packages("io.narayana.lra.filter"); register(new AbstractBinder(){ @Override protected void configure() { bind(LRAParticipantRegistry.class) .to(LRAParticipantRegistry.class); } }); } } {code} * However, the LRAParticipantRegistry has to be public. [~mmusgrov] Is it possible to make the LRAParticipantRegistry public in the implementation? Once it will be public, I can create an example of how to use LRA in the Spring Boot + JAX-RS(jersey) service to the Narayana lra quickstart (flight_5.9.8_working in Attachments). > 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-3161) Nested LRA doesn't start in the Spring Boot + JAX-RS application

by Matej Kralik (Jira)

[ https://issues.jboss.org/browse/JBTM-3161?page=com.atlassian.jira.plugin.... ] Matej Kralik commented on JBTM-3161: ------------------------------------ When I added the missing _LRAParticipantRegistry_ dependency to the application _JerseyConfig_, the application work* with the latest Narayana as well. Example of Jersey Config.: {code:java} @Component @ApplicationPath("/") public class JerseyConfig extends ResourceConfig { public JerseyConfig() throws URISyntaxException { register(WadlResource.class); register(FlightParticipant.class); packages("io.narayana.lra.filter"); register(new AbstractBinder(){ @Override protected void configure() { bind(LRAParticipantRegistry.class) .to(LRAParticipantRegistry.class); } }); } } {code} * However, the LRAParticipantRegistry has to be public. [~mmusgrov] Is it possible to make the LRAParticipantRegistry public in the implementation? Once it will be public, I can create an example of how to use LRA in the Spring Boot + JAX-RS(jersey) service to the Narayana lra quickstart (flight_5.9.8_working in Attachments). > 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues October 2019