June 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3152) XTS over SSL Quickstart Failure

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3152?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka updated JBTM-3152: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > XTS over SSL Quickstart Failure > ------------------------------- > > Key: JBTM-3152 > URL: https://issues.jboss.org/browse/JBTM-3152 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.9.5.Final > > > CI job narayana-quickstarts XTS over SSL Quickstart is failing regularly because the server is not reporting 'Transaction succeeded!': > > Doing the test by requesting 'http://localhost:8180/WSATSimpleServletClient' > > + curl -X GET http://localhost:8180/WSATSimpleServletClient > > + grep 'Transaction succeeded!' > See for example build: > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/285/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3149) LRA proxy test module failing with maven >=3.6.0

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3149: ----------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Michael Musgrove (was: Martin Stefanko) Resolution: Done > LRA proxy test module failing with maven >=3.6.0 > ------------------------------------------------ > > Key: JBTM-3149 > URL: https://issues.jboss.org/browse/JBTM-3149 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Major > > Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with > {code:java} > [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null > [ERROR] ----------------------------------------------------- > [ERROR] realm = plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0 > [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar > [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar > [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar > [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar > [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar > [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar > [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar > [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar > [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar > [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar > [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar > [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar > [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar > [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar > [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar > [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar > [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar > [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar > [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar > [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar > [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar > [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar > [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar > [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar > [ERROR] Number of foreign imports: 1 > {code} > {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR > {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR > {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3149) LRA proxy test module failing with maven >=3.6.0

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3149?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3149: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/narayana/pull/1453 > LRA proxy test module failing with maven >=3.6.0 > ------------------------------------------------ > > Key: JBTM-3149 > URL: https://issues.jboss.org/browse/JBTM-3149 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > Maven 3.6.0 is causing wildfly-swarm-plugin in lra proxy test module to fail with > {code:java} > [ERROR] Failed to execute goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package (default) on project lra-proxy-test: Execution default of goal org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package failed: An API incompatibility was encountered while executing org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0:package: java.lang.AbstractMethodError: null > [ERROR] ----------------------------------------------------- > [ERROR] realm = plugin>org.wildfly.swarm:wildfly-swarm-plugin:2018.5.0 > [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy > [ERROR] urls[0] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/wildfly-swarm-plugin/2018.5.0/wildfly-swarm-plugin-2018.5.0.jar > [ERROR] urls[1] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/fraction-metadata/2018.5.0/fraction-metadata-2018.5.0.jar > [ERROR] urls[2] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/meta-spi/2018.5.0/meta-spi-2018.5.0.jar > [ERROR] urls[3] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-javaee/2.0.0/shrinkwrap-descriptors-impl-javaee-2.0.0.jar > [ERROR] urls[4] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-base/2.0.0/shrinkwrap-descriptors-impl-base-2.0.0.jar > [ERROR] urls[5] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-spi/2.0.0/shrinkwrap-descriptors-spi-2.0.0.jar > [ERROR] urls[6] = file:/home/mstefank/.m2/repository/org/ow2/asm/asm/6.0/asm-6.0.jar > [ERROR] urls[7] = file:/home/mstefank/.m2/repository/com/eclipsesource/minimal-json/minimal-json/0.9.4/minimal-json-0.9.4.jar > [ERROR] urls[8] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/tools/2018.5.0/tools-2018.5.0.jar > [ERROR] urls[9] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/bootstrap/2018.5.0/bootstrap-2018.5.0.jar > [ERROR] urls[10] = file:/home/mstefank/.m2/repository/org/jboss/modules/jboss-modules/1.6.1.Final/jboss-modules-1.6.1.Final.jar > [ERROR] urls[11] = file:/home/mstefank/.m2/repository/org/yaml/snakeyaml/1.17/snakeyaml-1.17.jar > [ERROR] urls[12] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-api/1.2.6/shrinkwrap-api-1.2.6.jar > [ERROR] urls[13] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-spi/1.2.6/shrinkwrap-spi-1.2.6.jar > [ERROR] urls[14] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/shrinkwrap-impl-base/1.2.6/shrinkwrap-impl-base-1.2.6.jar > [ERROR] urls[15] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-jboss/2.0.0/shrinkwrap-descriptors-api-jboss-2.0.0.jar > [ERROR] urls[16] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-javaee/2.0.0/shrinkwrap-descriptors-api-javaee-2.0.0.jar > [ERROR] urls[17] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api-base/2.0.0/shrinkwrap-descriptors-api-base-2.0.0.jar > [ERROR] urls[18] = file:/home/mstefank/.m2/repository/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-impl-jboss/2.0.0/shrinkwrap-descriptors-impl-jboss-2.0.0.jar > [ERROR] urls[19] = file:/home/mstefank/.m2/repository/net/lingala/zip4j/zip4j/1.3.2/zip4j-1.3.2.jar > [ERROR] urls[20] = file:/home/mstefank/.m2/repository/org/wildfly/swarm/spi/2018.5.0/spi-2018.5.0.jar > [ERROR] urls[21] = file:/home/mstefank/.m2/repository/org/jboss/jandex/2.0.3.Final/jandex-2.0.3.Final.jar > [ERROR] urls[22] = file:/home/mstefank/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar > [ERROR] urls[23] = file:/home/mstefank/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar > [ERROR] Number of foreign imports: 1 > {code} > {{~/apps/apache-maven-3.6.1/bin/mvn verify -Parq}} -- ERROR > {{~/apps/apache-maven-3.6.0/bin/mvn verify -Parq}} -- ERROR > {{~/apps/apache-maven-3.5.4/bin/mvn verify -Parq}} -- PASS -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3103) LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3103?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3103: ----------------------------------- Fix Version/s: 5.next > LRA api-particpant quickstart needs aligning with the latest MP LRA spec changes > -------------------------------------------------------------------------------- > > Key: JBTM-3103 > URL: https://issues.jboss.org/browse/JBTM-3103 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > This quickstart depends on LRAParticipantDeserializer to recreate participants during crash recovery but [MP LRA issue #61|https://github.com/eclipse/microprofile-lra/issues/61] has removed this class. The alternative registration mechanism is still outstanding [see the comments on issue #35|https://github.com/eclipse/microprofile-lra/issues/35] for a discussion of the new way of registering participants. > Until a PR is raised for this issue I would like to disable the quickstarts that utilise LRAParticipantDeserializer. > Note that this has only just become an issue since previouslythe Narayana implementation of LRA depended on a specific snapshot build in the eclipse repo (since the LRA spec is in flux), but snapshots are purged after a month so the old way of registering participants is no longer available. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3121?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3121: ----------------------------------- Fix Version/s: 6.later > Create Quarkus LRA extension > ---------------------------- > > Key: JBTM-3121 > URL: https://issues.jboss.org/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.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3114) LRA module should depend on a specific snapshot build

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3114?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3114: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA module should depend on a specific snapshot build > ----------------------------------------------------- > > Key: JBTM-3114 > URL: https://issues.jboss.org/browse/JBTM-3114 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.3.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The Narayana implementation of the LRA spec should depend on specific LRA API snapshot builds (since the LRA API is a moving target). > This problem has been fixed in JBTM-3091 and reintroduced in https://github.com/jbosstm/narayana/pull/1408/files#diff-14510da88f467b20.... > Current version of the implementation is running against latest build: > - api - 1.0-20190222.071200-278 > - tck - 1.0-20190222.071201-278 -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3082) Coordinator reports LRA as compensating when the participant is not able to finish complete method invocation immediately

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3082?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3082: ----------------------------------- Fix Version/s: 5.next > Coordinator reports LRA as compensating when the participant is not able to finish complete method invocation immediately > ------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3082 > URL: https://issues.jboss.org/browse/JBTM-3082 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Martin Stefanko > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > If the participant cannot finish the complete method invocation immediately and thus returns 202 ACCEPTED return code and then somebody calls get status of the finishing LRA, the coordinator reports it as CompensatorStatus.Compensating instead of CompensatorStatus.Completing. > The status of the finishing LRA is changed to Compensating here [1] possibly because of this line [2] as heuristicList is not empty. > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/s... > [2] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/s... -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2997) Ensure that any LRA coordinator instance can control any LRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2997?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2997: ----------------------------------- Fix Version/s: 6.later (was: 5.next) > Ensure that any LRA coordinator instance can control any LRA > ------------------------------------------------------------ > > Key: JBTM-2997 > URL: https://issues.jboss.org/browse/JBTM-2997 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: LRA > Affects Versions: 5.8.0.Final > Reporter: Michael Musgrove > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 6.later > > > Currently the management of an LRA is restricted to the coordinator that created it. It would be preferable to have the option of allowing any coordinator be able to manage any LRA. The motivation for this feature is to enhance the usability of LRAs in cloud based environments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2959?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2959: ----------------------------------- Fix Version/s: 6.later (was: 5.next) > Allow different LRA coordinators to share an object store > --------------------------------------------------------- > > Key: JBTM-2959 > URL: https://issues.jboss.org/browse/JBTM-2959 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 6.later > > > Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. > If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Some notes on the current implementation: > # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). > # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). > # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. > # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. > # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2953) Support asynchronous LRA participants

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-2953?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-2953. ---------------------------------- Resolution: Done The implementation passes the relevant TCK tests defined as examples in the spec: https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asc... and as TCK tests: https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java... and as participants: https://github.com/eclipse/microprofile-lra/blob/master/tck/src/main/java... > Support asynchronous LRA participants > ------------------------------------- > > Key: JBTM-2953 > URL: https://issues.jboss.org/browse/JBTM-2953 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > When an asynchronous jax-rs method is annotated as an LRA (ie has the @LRA annotation), for example: > {code} > @GET > @LRA > public void someAction(@Suspended AsyncResponse ar) throws InterruptedException { > ... > } > {code} > the LRA filter does not respect the asynchronous nature of the call. > What needs to happen is for LRA jax-rs filter (ServerLRAFilter.java) to issue an asynchronous join request to the coordinator and to link that future to the jax-rs resource AsyncResponse callback. > And since the ServerLRAFilter cannot immediately supply the LRAId to the resource method we also need a method on LRAClient analogous to getCurrent but which returns a Future for the lra id. -- This message was sent by Atlassian Jira (v7.12.1#712002)

4 years, 10 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 June 2019