March 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3127) LRA TCK Test Failure (mixedMultiLevelNestedActivity)

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3127: -------------------------------------- Summary: LRA TCK Test Failure (mixedMultiLevelNestedActivity) Key: JBTM-3127 URL: https://issues.jboss.org/browse/JBTM-3127 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next This TCK failure was introduced when MP-LRA PR https://github.com/eclipse/microprofile-lra/pull/115 removed the Java Client API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3126) @LRA may begin a nested LRA without the presence of @NestedLRA

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3126?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1432 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > @LRA may begin a nested LRA without the presence of @NestedLRA > --------------------------------------------------------------- > > Key: JBTM-3126 > URL: https://issues.jboss.org/browse/JBTM-3126 > 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 a JAX-RS method is invoked and the following conditions are met: > - the invoked method is annotated with LRA.Type.REQUIRES_NEW; > - the invoked method is not annotated with @Nested; > - there is an LRA context present on the incoming request > then the implementation (of the LRA spec) will begin a nested LRA which is contrary to the specified behaviour. Note that there is an [outstanding issue regarding nested LRAs|https://github.com/eclipse/microprofile-lra/issues/117] but this issue affects the implementation of the current specification and needs fixing. > In addition there is also the situation where the outbound JAX-RS request filter may override the LRA context header (this issue can be reproduced by starting an LRA and then starting a JAX-RS request with a different "LRA context header" - the expected behaviour in this case is to run the request with the context set by the user. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3126) @LRA may begin a nested LRA without the presence of @NestedLRA

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3126: -------------------------------------- Summary: @LRA may begin a nested LRA without the presence of @NestedLRA Key: JBTM-3126 URL: https://issues.jboss.org/browse/JBTM-3126 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next If a JAX-RS method is invoked and the following conditions are met: - the invoked method is annotated with LRA.Type.REQUIRES_NEW; - the invoked method is not annotated with @Nested; - there is an LRA context present on the incoming request then the implementation (of the LRA spec) will begin a nested LRA which is contrary to the specified behaviour. Note that there is an [outstanding issue regarding nested LRAs|https://github.com/eclipse/microprofile-lra/issues/117] but this issue affects the implementation of the current specification and needs fixing. In addition there is also the situation where the outbound JAX-RS request filter may override the LRA context header (this issue can be reproduced by starting an LRA and then starting a JAX-RS request with a different "LRA context header" - the expected behaviour in this case is to run the request with the context set by the user. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-2912: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Thomas Jenkinson > Priority: Major > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-2867: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Thomas Jenkinson > Assignee: Thomas Jenkinson > Priority: Major > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef209... > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef209... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-2967: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-2968: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Some JTS quickstarts run with JacORB > ------------------------------------ > > Key: JBTM-2968 > URL: https://issues.jboss.org/browse/JBTM-2968 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are: > ArjunaJTS/pom.xml > ArjunaJTS/standalone/pom.xml > ArjunaJTS/trailmap/pom.xml -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3020: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondrej Chaloupka > Priority: Major > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3046: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3051) LRA test timeLimit failure on JDK 9

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3051?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson updated JBTM-3051: ----------------------------------- Fix Version/s: 5.next (was: 5.9.5.Final) > LRA test timeLimit failure on JDK 9 > ----------------------------------- > > Key: JBTM-3051 > URL: https://issues.jboss.org/browse/JBTM-3051 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > Whilst fixing issue JBTM-2942 I noticed that the test timeLimitRequiredLRA fails consistently with the reason: > {quote} > 2018-08-14 11:38:00,244 INFO [stdout] (pool-7-thread-1) testName.getMethodName(): WARNING: test did not close http://localhost:8080/lra-coordinator/0_ffff0a3f00d6_245c07ef_5b72b0d1_104 > {quote} > I have temporarily disabled the test in the TCK runner: > {quote} > rts/lra/lra-tck/tck/src/main/java/org/eclipse/microprofile/lra/tck/RunTck.java > {quote} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 8 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 March 2019