December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7785) Transaction manager runtime configuration is not enriched with system properties from standalone xml

by Tom Jenkinson (JIRA)

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

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7785) Transaction manager runtime configuration is not enriched with system properties from standalone xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-7785?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-7785: -------------------------------- Steps to Reproduce: (was: Could be reproduced with crashrec testsuite where system property {{RecoveryEnvironmentBean.expiryScannerClassNames}} is defined as application container system property. {code} git clone http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git export JBOSS_HOME=... (downloadable at http://download.eng.brq.redhat.com/devel/candidates/JBEAP/) mvn clean verify -am -pl jbossts -DfailIfNoTests=false -fn -Djbossts.noJTS -Dtest=JPAProxyCrashRecoveryTestCase#testAAExpiryScanner {code}) > 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 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7785) Transaction manager runtime configuration is not enriched with system properties from standalone xml

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-7785?page=com.atlassian.jira.plugin.... ] Tom Jenkinson moved JBEAP-7856 to WFLY-7785: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7785 (was: JBEAP-7856) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Transactions (was: Transactions) Affects Version/s: (was: 7.1.0.DR9) > 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 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-208) Update SASL mechanism testing to also be domain backed.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/ELY-208?page=com.atlassian.jira.plugin.sy... ] Kabir Khan commented on ELY-208: -------------------------------- [~dlofthouse] assigning to you so you can close if it is out of date > Update SASL mechanism testing to also be domain backed. > ------------------------------------------------------- > > Key: ELY-208 > URL: https://issues.jboss.org/browse/ELY-208 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta19 > > > There may be a little bit more work required before this is possible but we need to ensure SASL mechanisms are also tested using a CallbackHandler they are likely to encounter which will really be the one from ServerAuthenticationContext. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-278) Add CBH to AuthenticationConfiguration overriding *some* callbacks

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/ELY-278?page=com.atlassian.jira.plugin.sy... ] Kabir Khan reassigned ELY-278: ------------------------------ Assignee: Darran Lofthouse (was: Kabir Khan) > Add CBH to AuthenticationConfiguration overriding *some* callbacks > ------------------------------------------------------------------ > > Key: ELY-278 > URL: https://issues.jboss.org/browse/ELY-278 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > > SetPasswordCallbackHandlerAuthenticationConfiguration only allows overriding of PasswordCallback, CredentialCallback and CredentialParameterCallback. For OTP I need to handle PasswordCallback and ParameterCallback, as part of one class. > SetCallbackHandlerAuthenticationConfiguration on the other hand seems to consider being the only callback, meaning for OTP I will not be able to reuse logic for handling the principal and the extended choice (added as ELY-274) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-278) Add CBH to AuthenticationConfiguration overriding *some* callbacks

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/ELY-278?page=com.atlassian.jira.plugin.sy... ] Kabir Khan commented on ELY-278: -------------------------------- [~dlofthouse] assigning to you so you can close this if it is out of date > Add CBH to AuthenticationConfiguration overriding *some* callbacks > ------------------------------------------------------------------ > > Key: ELY-278 > URL: https://issues.jboss.org/browse/ELY-278 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > > SetPasswordCallbackHandlerAuthenticationConfiguration only allows overriding of PasswordCallback, CredentialCallback and CredentialParameterCallback. For OTP I need to handle PasswordCallback and ParameterCallback, as part of one class. > SetCallbackHandlerAuthenticationConfiguration on the other hand seems to consider being the only callback, meaning for OTP I will not be able to reuse logic for handling the principal and the extended choice (added as ELY-274) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-208) Update SASL mechanism testing to also be domain backed.

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/ELY-208?page=com.atlassian.jira.plugin.sy... ] Kabir Khan reassigned ELY-208: ------------------------------ Assignee: Darran Lofthouse (was: Kabir Khan) > Update SASL mechanism testing to also be domain backed. > ------------------------------------------------------- > > Key: ELY-208 > URL: https://issues.jboss.org/browse/ELY-208 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta19 > > > There may be a little bit more work required before this is possible but we need to ensure SASL mechanisms are also tested using a CallbackHandler they are likely to encounter which will really be the one from ServerAuthenticationContext. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2112) Non atomic update of volatile fields in ManagedServerSocketBinding and GeneralTimeoutHandler

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2112?page=com.atlassian.jira.plugi... ] Kabir Khan moved JBEAP-7855 to WFCORE-2112: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2112 (was: JBEAP-7855) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) Affects Version/s: (was: 7.1.0.DR8) > Non atomic update of volatile fields in ManagedServerSocketBinding and GeneralTimeoutHandler > -------------------------------------------------------------------------------------------- > > Key: WFCORE-2112 > URL: https://issues.jboss.org/browse/WFCORE-2112 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: Kabir Khan > > https://github.com/wildfly/wildfly-core/blob/master/network/src/main/java... > https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > Volatile fields are not synchronized on update. > I think {{AtomicLong}} could be used instead of {{volatile long}} or update should be synchronized. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2112) Non atomic update of volatile fields in ManagedServerSocketBinding and GeneralTimeoutHandler

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2112?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2112: ------------------------------- Affects Version/s: 3.0.0.Alpha15 > Non atomic update of volatile fields in ManagedServerSocketBinding and GeneralTimeoutHandler > -------------------------------------------------------------------------------------------- > > Key: WFCORE-2112 > URL: https://issues.jboss.org/browse/WFCORE-2112 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha15 > Reporter: Rostislav Svoboda > Assignee: Kabir Khan > > https://github.com/wildfly/wildfly-core/blob/master/network/src/main/java... > https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/jav... > Volatile fields are not synchronized on update. > I think {{AtomicLong}} could be used instead of {{volatile long}} or update should be synchronized. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-7728: ----------------------------------- [~swd847] yes, see discussion on JBEAP-6731 about that > Increased Memory footprint in recent builds > ------------------------------------------- > > Key: WFLY-7728 > URL: https://issues.jboss.org/browse/WFLY-7728 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended. > Test scenario: > # Start EAP instance. > # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times. > We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2016