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 closed JBTM-3067. ------------------------------- > 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, 2 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 closed JBTM-3111. ------------------------------- > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-3107. ------------------------------- > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 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 closed JBTM-3109. ------------------------------- > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3087) Ensure the LRA implementation is up to date

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-3087. ------------------------------- > Ensure the LRA implementation is up to date > ------------------------------------------- > > Key: JBTM-3087 > URL: https://issues.jboss.org/browse/JBTM-3087 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 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 closed JBTM-3110. ------------------------------- > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3087) Ensure the LRA implementation is up to date

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3087?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3087: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final (was: 5.next) Resolution: Done > Ensure the LRA implementation is up to date > ------------------------------------------- > > Key: JBTM-3087 > URL: https://issues.jboss.org/browse/JBTM-3087 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Affects Versions: 5.9.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The microprofile-lra API has undergone a number of changes recently. The narayana implementation of the specification needs updating to match the new version of it. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3107) Some of the logging messages miss parameter's values to be printed

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3107?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3107: -------------------------------- Fix Version/s: 5.9.3.Final > Some of the logging messages miss parameter's values to be printed > ------------------------------------------------------------------ > > Key: JBTM-3107 > URL: https://issues.jboss.org/browse/JBTM-3107 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > Fix For: 5.9.3.Final > > > Some of the logging messages from Narayana is not enhanced with the parameters values defined in the {{i18N}} logger. For example this message is never enhanced with the values. > {code} > ARJUNA016133: Cant create a new instance of Xid of uid {0}, is branch: {1}, eisname: {2} > {code} > The reason is usage of quotes {{'}} in the log message pattern. The quote is not expected of not being closed (see https://docs.oracle.com/javase/8/docs/api/java/text/MessageFormat.html). The solution is to change strings like {{Can't}} to {{Cannot}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3093) Disable the maven site plugin for the LRA module

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3093?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3093: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final (was: 5.next) Resolution: Done > Disable the maven site plugin for the LRA module > ------------------------------------------------ > > Key: JBTM-3093 > URL: https://issues.jboss.org/browse/JBTM-3093 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.9.3.Final > > > The narayana code coverage profile invokes the maven site goal so that the output can be viewed easily. > > Now LRA relies on microprofile-lra-api snapshot builds but the site plugin appears to resolve to the latest snapshot (rather than a particular snapshot build) and since microprofile-lra-api regularly undergoes changes there are compilation failures. > This JIRA proposes that we disable the site plugin for the LRA module. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3113) LRA coordinator defines in depenedencies whole microprofile stack

by Tom Jenkinson (Jira)

[ https://issues.jboss.org/browse/JBTM-3113?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-3113: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.9.3.Final Resolution: Done > LRA coordinator defines in depenedencies whole microprofile stack > ----------------------------------------------------------------- > > Key: JBTM-3113 > URL: https://issues.jboss.org/browse/JBTM-3113 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.9.3.Final > > > The LRA coordinator defines the depenendency on whole MicroProfile stack. That's not necessary as it uses JAX-RS and CDI. The depenencies needed up to that will be resolved by the Wfly Swarm/Thorntail runtime. If we define whole stack then Wfly Swarm loads to the runtime unnecessary dependencies which makes the fat jar bigger than it needs to be. Plus the start time the container could be lower when we use only the dependencies which are really needed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

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 February 2019