[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years