December 2018 - jbossts-issues - Jboss List Archives

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2867: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.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: Tom Jenkinson > Assignee: Tom 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, 11 months

1
0
0 / 0

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3020: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.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: Ondra 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, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3019) Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3019?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3019: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3019 > URL: https://issues.jboss.org/browse/JBTM-3019 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.8.1.Final > Environment: Docker enabled Jenkins slaves > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Minor > Fix For: 5.next > > > h3. Problem > The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images: > {code} > [root@karm-centos7-x86-64 ~]# docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > docker.io/postgres 9.4 26bd9b04b948 6 days ago 232 MB > docker.io/postgres 10 0965cdc98045 6 days ago 234 MB > docker.io/postgres <none> ed5db6e669ff 7 weeks ago 263 MB > docker.io/postgres <none> 30121e967865 7 weeks ago 289 MB > [root@karm-centos7-x86-64 ~]# docker ps -a > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > [root@karm-centos7-x86-64 ~]# > {code} > Although it leaves stray container volumes for some reason: > {code} > [root@karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes > 15G /var/lib/docker-latest/volumes > [root@karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l > 409 > {code} > It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway. > h3. Call to action > Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/...] is supposed to be enough to not only remove the container but to also remove its volume. > h3. Workaround > {code} > docker volume prune > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2968: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.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, 11 months

1
0
0 / 0

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2967: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.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, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3071) Windows automation of the LRA examples quickstarts

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3071?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3071: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > Windows automation of the LRA examples quickstarts > -------------------------------------------------- > > Key: JBTM-3071 > URL: https://issues.jboss.org/browse/JBTM-3071 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA examples quickstarts (https://issues.jboss.org/browse/JBTM-3063) contain a bash script to run the examples. We need the equivalent for running on Windows. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3065: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > Check that starting LRA's via CDI and API in the same method works > ------------------------------------------------------------------ > > Key: JBTM-3065 > URL: https://issues.jboss.org/browse/JBTM-3065 > 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 > > > The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation. > If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's. > The following code shows an example: > {code} > @PUT > @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry > public String doInTransaction() { > URL lraId = lraClient.startLRA(...); // starts a nested LRA > lraClient.join(...) // join the nested LRA > lraClient.closeLRA(lraId); // close the nested LRA > // assert that the nested callbacks were invoked > // assert that the callbacks for the outer LRA have not been called yet > } > {code} > Similar comments apply if the resource joins via the LRAManagement API: > {code} > @Inject > private LRAManagement lraManagement; > public String doInTransaction() { > lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS); > // etc > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3062) Include a test for LRA context propagation across a "non-LRA aware" service

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3062?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3062: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > Include a test for LRA context propagation across a "non-LRA aware" service > --------------------------------------------------------------------------- > > Key: JBTM-3062 > URL: https://issues.jboss.org/browse/JBTM-3062 > 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 > > > If a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and service A in turn calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. A test is needed for this behaviour. > This issue relates to https://github.com/eclipse/microprofile-lra/issues/7 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3058) Add STM tests that verify nested transactions are closed

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3058?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3058: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > Add STM tests that verify nested transactions are closed > -------------------------------------------------------- > > Key: JBTM-3058 > URL: https://issues.jboss.org/browse/JBTM-3058 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > STM implements "Closed Nested Transactions" as opposed to Flattened or Open. We need a test which demonstrates that nested transactions follow the closed model. > Furthermore, STM implementations can differ in how transactional code and non-transactional code are isolated from each other (with respect to visibility of updates during a transaction). Add a test that verifies that we use the "Weak Isolation" model. > Details of the expected behaviour is covered in the Sept 2018 jbossts blog entitled "[Tips on how to evaluate STM implementations|http://example.com|https://jbossts.blogspot.com/2018/09/t...]" -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 11 months

1
0
0 / 0

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

by Ondra Chaloupka (Jira)

[ https://issues.jboss.org/browse/JBTM-3051?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-3051: ---------------------------------- Fix Version/s: 5.next (was: 5.9.2.Final) > LRA test timeLimitRequiredLRA 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, 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 December 2018