February 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3067) Build and run the narayana with JDK-11

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3067?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3067: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Build and run the narayana with JDK-11 > -------------------------------------- > > Key: JBTM-3067 > URL: https://issues.jboss.org/browse/JBTM-3067 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Critical > Fix For: 5.9.3.Final > > > The jdk-11 could be downloaded from https://jdk.java.net/11/ and the most important feature that impacts us is [JEP 320: Remove the Java EE and CORBA Modules|https://openjdk.java.net/jeps/320] > The CI job is http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-jdk-11/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3109) Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3109?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3109: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Refactoring LRA tck tests to comply with Arquillian refactoring in LRA spec > --------------------------------------------------------------------------- > > Key: JBTM-3109 > URL: https://issues.jboss.org/browse/JBTM-3109 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > The LRA specification started to use the Arquillian for running the TCK tests - see issue https://github.com/eclipse/microprofile-lra/issues/94 > The Narayana LRA client needs to comply with this change and the setup for startin the tests need to be refactored. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3111) Periodic recovery thread and thread terminating transaction manager can deadlock

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3111?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3111: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > Periodic recovery thread and thread terminating transaction manager can deadlock > -------------------------------------------------------------------------------- > > Key: JBTM-3111 > URL: https://issues.jboss.org/browse/JBTM-3111 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > Fix For: 5.9.3.Final > > > The fix for issue WFLY-10841, which was causing the WFLY was not cleanly finished, brought potential dead lock on threads of periodic recovery and the thread terminating the transaction manager. > When looking to WFLY-11706 the thread dump talks about > {code} > "Periodic Recovery": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.setScanState(XARecoveryModule.java:1088) > - waiting to lock <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:240) > - locked <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816) > at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > "ServerService Thread Pool -- 8": > at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.removeXAResourceRecoveryHelper(XARecoveryModule.java:119) > - waiting to lock <0xc8f64470> (a com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule) > - locked <0xc8f80918> (a java.util.concurrent.atomic.AtomicInteger) > at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.removeXAResourceRecovery(RecoveryManagerService.java:129) > at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryRegistryImpl.removeXAResourceRecovery(XAResourceRecoveryRegistryImpl.java:63) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.stopService(XaDataSourceService.java:66) > - locked <0xc8f95a38> (a org.jboss.as.connector.subsystems.datasources.XaDataSourceService) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$1.run(AbstractDataSourceService.java:188) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > We need to avaoid this dead lock. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3110) JNDIBean CDI Deployment Failure

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3110?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3110: -------------------------------- Fix Version/s: 5.9.3.Final (was: 5.9.1.Final) > JNDIBean CDI Deployment Failure > ------------------------------- > > Key: JBTM-3110 > URL: https://issues.jboss.org/browse/JBTM-3110 > Project: JBoss Transaction Manager > Issue Type: Bug > Environment: Wildfly 16 Beta 1 > Reporter: Cody Lerum > Assignee: Matej Novotny > Priority: Major > Fix For: 5.9.3.Final > > > While testing Wildfly 16.0.0.Beta1 with an existing working (Wildfly 14.0.1) project we were unable to deploy the war as weld threw an exception. > {code} > org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001477: The bean Managed Bean [class co.cfly.oss.lerg.rateCenter.inventoryRequest.InventoryRequestView] with qualifiers [@Default @Any @Named] declares a passivating scope but has a(n) Interceptor [class com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired intercepts @Transactional] with a non-passivation-capable dependency com.arjuna.ats.jta.cdi.JNDIBean@12e2cb9f > at org.jboss.weld.bootstrap.Validator.validateInterceptorDecoratorInjectionPointPassivationCapable(Validator.java:480) > at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:225) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:175) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:526) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:64) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > I opened WFLY-11716 and had [~manovotn] take a look. The issue is due to the JNDIBean not implementing PassivationCapable. He has also added a suggested fix in the issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

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

by Tom Jenkinson (Jira)

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

1
0
0 / 0

[JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3042?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3042: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.Final) > API to get detailed LRA information should not include stats type data > ---------------------------------------------------------------------- > > Key: JBTM-3042 > URL: https://issues.jboss.org/browse/JBTM-3042 > 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 interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface > [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/ma... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

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

by Tom Jenkinson (Jira)

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

1
0
0 / 0

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

by Tom Jenkinson (Jira)

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

1
0
0 / 0

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

by Tom Jenkinson (Jira)

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

1
0
0 / 0

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

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2967: -------------------------------- Fix Version/s: 5.next (was: 5.9.3.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, 9 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 February 2019