[
https://issues.jboss.org/browse/WFLY-7785?page=com.atlassian.jira.plugin....
]
Tom Jenkinson updated WFLY-7785:
--------------------------------
Description:
I can see trouble and regression against behavior of configuration of transaction manager
which is defined inside of setting MBeans is not enriched from system properties which are
defined as part of standalone .xml file.
When system property is set in standalone xml file as
{code}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames"
value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{code}
then it's not propagated to {{RecoveryEnvironmentBean}} when container is started.
The TransactionExtension initialize method is touching classes that perform static
initialization using system props which is too early:
{code}
"ServerService Thread Pool -- 21@3635" prio=5 tid=0x30 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
com.arjuna.common.util.propertyservice.PropertiesFactory.initPropertiesFactory(PropertiesFactory.java:53)
- locked <0x1389> (a java.lang.Class)
at
com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:36)
at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:86)
at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
at
com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
at
org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.<init>(TransactionSubsystemRootResourceDefinition.java:518)
at
org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition.registerAttributes(TransactionSubsystemRootResourceDefinition.java:314)
at
org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:104)
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225)
at
org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
at
org.jboss.as.txn.subsystem.TransactionExtension.initialize(TransactionExtension.java:104)
at
org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
at
org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
at
org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
at
org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
A likely fix is to just not store a ref to coordinatorEnvironmentBean in
TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just find it and use
it in applyUpdateToRuntime/revertUpdateToRuntime neither of which will get called before
system properties are set. They don’t get called at all if the user doesn’t do a
write-attribute op to change that attribute.
was:
I can see trouble and regression against behavior of 7.0.0.GA (and other prior 7.1.0 DR
versions) where configuration of transaction manager which is defined inside of setting
MBeans is not enriched from system properties which are defined as part of standalone .xm
file.
When system property is set in standalone xml file as
{code}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames"
value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{code}
then it's not propagated to {{RecoveryEnvironmentBean}} when container is started.
I could see that method loading system properties at AbstractPropertiesFactory
(
https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna...)
does not provide those which are part of the container config. That worked with DR8 fine.
I didn't go deeper if this is really issue of TM/integration or some change in
container.
Transaction manager runtime configuration is not enriched with system
properties from standalone xml
----------------------------------------------------------------------------------------------------
Key: WFLY-7785
URL:
https://issues.jboss.org/browse/WFLY-7785
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Ondra Chaloupka
Assignee: Tom Jenkinson
Priority: Critical
I can see trouble and regression against behavior of configuration of transaction manager
which is defined inside of setting MBeans is not enriched from system properties which are
defined as part of standalone .xml file.
When system property is set in standalone xml file as
{code}
<system-properties>
<property name="RecoveryEnvironmentBean.expiryScannerClassNames"
value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner
com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
</system-properties>
{code}
then it's not propagated to {{RecoveryEnvironmentBean}} when container is started.
The TransactionExtension initialize method is touching classes that perform static
initialization using system props which is too early:
{code}
"ServerService Thread Pool -- 21@3635" prio=5 tid=0x30 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
com.arjuna.common.util.propertyservice.PropertiesFactory.initPropertiesFactory(PropertiesFactory.java:53)
- locked <0x1389> (a java.lang.Class)
at
com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:36)
at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:86)
at
com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
at
com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
at
org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler.<init>(TransactionSubsystemRootResourceDefinition.java:518)
at
org.jboss.as.txn.subsystem.TransactionSubsystemRootResourceDefinition.registerAttributes(TransactionSubsystemRootResourceDefinition.java:314)
at
org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:104)
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:225)
at
org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:706)
at
org.jboss.as.txn.subsystem.TransactionExtension.initialize(TransactionExtension.java:104)
at
org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131)
at
org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:104)
at
org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:144)
at
org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
A likely fix is to just not store a ref to coordinatorEnvironmentBean in
TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler. Just find it and use
it in applyUpdateToRuntime/revertUpdateToRuntime neither of which will get called before
system properties are set. They don’t get called at all if the user doesn’t do a
write-attribute op to change that attribute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)