[wildfly-dev] Accessing system properties in a subsystem
Tom Jenkinson
tom.jenkinson at redhat.com
Tue Dec 13 09:19:04 EST 2016
Yeah - that must be it thanks!
On 13 December 2016 at 13:46, Brian Stansberry <brian.stansberry at redhat.com>
wrote:
> Great. :)
>
> It looks like the TransactionSubsystemRootResourceDefinition$StatisticsEnabledHandler
> logic came in about a month ago. The issue may have surfaced more recently
> than that if the test that revealed it was not part of CI, but was
> something extended that Red Hat QE runs against periodic internal builds.
> Those happen every few weeks.
>
> > On Dec 13, 2016, at 5:55 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> >
> > Yeah, moving the lookup to the area you mentioned worked - thanks again!
> >
> > On 13 December 2016 at 10:54, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > Thanks, I will take a look. Did this change recently? If not I am at a
> loss why it is starting to fail an existing test.
> >
> > On 12 December 2016 at 21:33, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >
> > > On Dec 12, 2016, at 3:21 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >
> > > This is the problem: the TransactionExtension initialize method of
> touching classes that result in doing static initialization stuff that
> reads the system props at that point, which is too early:
> > >
> >
> > s/of touching/is touching/g
> >
> > 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.
> >
> > > "ServerService Thread Pool -- 21 at 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.TransactionSubsystemRootResour
> ceDefinition$StatisticsEnabledHandler.<init>(
> TransactionSubsystemRootResourceDefinition.java:518)
> > > at org.jboss.as.txn.subsystem.TransactionSubsystemRootResour
> ceDefinition.registerAttributes(TransactionSubsystemRootResour
> ceDefinition.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)
> > >
> > >
> > >> On Dec 12, 2016, at 2:50 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > >>
> > >> Thanks for the input/
> > >>
> > >> This is the point I do not think the property has been set by:
> > >>
> > >> "MSC service thread 1-3 at 2595" prio=5 tid=0x14 nid=NA runnable
> > >> java.lang.Thread.State: RUNNABLE
> > >> at com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.
> getExpiryScannerClassNames(RecoveryEnvironmentBean.java:336)
> > >> - locked <0x1bb6> (a com.arjuna.ats.arjuna.common.
> RecoveryEnvironmentBean)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(
> NativeMethodAccessorImpl.java:-1)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> > >> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.handleGroupProperty(BeanPopulator.java:263)
> > >> at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.configureFromProperties(BeanPopulator.java:170)
> > >> at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> > >> at com.arjuna.common.internal.util.propertyservice.
> BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> > >> at com.arjuna.ats.arjuna.common.recoveryPropertyManager.
> getRecoveryEnvironmentBean(recoveryPropertyManager.java:34)
> > >> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.
> start(ArjunaRecoveryManagerService.java:96)
> > >> - locked <0x1bd2> (a org.jboss.as.txn.service.
> ArjunaRecoveryManagerService)
> > >> at org.jboss.msc.service.ServiceControllerImpl$
> StartTask.startService(ServiceControllerImpl.java:1963)
> > >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> ServiceControllerImpl.java:1896)
> > >> 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)
> > >>
> > >> (that is output from the debugger)
> > >>
> > >> Once releasing that thread and letting the container continue startup
> I see this execute:
> > >> 2016-12-12 20:46:49,731 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 5c7e7735 handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> > >> 2016-12-12 20:46:49,787 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at f15c8f7 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> > >>
> > >> I believe this is different to previous behaviour as I have had a
> defect raised against TX: https://issues.jboss.org/browse/JBEAP-7820.
> It's possible that there is a regression in Narayana (somehow) if nothing
> changed in this area in the core itself.
> > >>
> > >> Thanks for your input,
> > >> Tom
> > >>
> > >>
> > >>
> > >>
> > >> On 12 December 2016 at 20:15, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >> This works fine for me. Adding that xml snippet to standalone.xml
> after the <extensions> element I see the property being set during boot
> before any processing of subsystem operations begins.
> > >>
> > >>> On Dec 12, 2016, at 1:55 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> > >>>
> > >>> I don’t see anything in the organization of boot ops that would have
> changed the ordering, and the add op for that system property should be
> executing prior to the subsystem ops. I’ll see if I can reproduce.
> > >>>
> > >>>> On Dec 12, 2016, at 12:10 PM, Kabir Khan <kabir.khan at jboss.com>
> wrote:
> > >>>>
> > >>>> Where are you trying to use the system property from? They should
> only be attempted resolved during the RUNTIME stage, not MODEL.
> > >>>>> On 12 Dec 2016, at 18:00, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> I have a subsystem that configures itself from system properties.
> > >>>>>
> > >>>>> For example:
> > >>>>> <system-properties>
> > >>>>> <property name="RecoveryEnvironmentBean.expiryScannerClassNames"
> value="com.arjuna.ats.internal.arjuna.recovery.
> ExpiredTransactionStatusManagerScanner com.arjuna.ats.internal.
> arjuna.recovery.AtomicActionExpiryScanner"/>
> > >>>>> </system-properties>
> > >>>>>
> > >>>>> In earlier revisions of WFLY this worked fine. However I am now
> seeing that the system property is not set until after my subsystem has
> started. I can tell this as I have breakpoints on where I process the
> property. I can see "MSC service thread 1-4" attempting to process the
> property (which is not set). I do later see messages that suggest the
> system property is set but at that the later point:
> > >>>>>
> > >>>>> 2016-12-12 17:57:48,042 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.server.operations.SystemPropertyAddHandler at 784c8c5f handling
> add in address [("system-property" => "RecoveryEnvironmentBean.expiryScannerClassNames")]
> is {"outcome" => "success"}
> > >>>>> 2016-12-12 17:57:48,093 TRACE [org.jboss.as.controller.management-operation]
> (Controller Boot Thread) Final response for step handler
> org.jboss.as.controller.ValidateModelStepHandler at 87b4493 handling
> internal-model-validation in address [("system-property" =>
> "RecoveryEnvironmentBean.expiryScannerClassNames")] is {"outcome" =>
> "success"}
> > >>>>>
> > >>>>> Does my subsystem need to depend on something to get the old
> behaviour of being started after system properties are processed?
> > >>>>>
> > >>>>> My subsystem is the transaction one and the service is the
> recovery manager.
> > >>>>>
> > >>>>> Thanks!
> > >>>>> Tom
> > >>>>> _______________________________________________
> > >>>>> wildfly-dev mailing list
> > >>>>> wildfly-dev at lists.jboss.org
> > >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> wildfly-dev mailing list
> > >>>> wildfly-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >>>
> > >>> --
> > >>> Brian Stansberry
> > >>> Manager, Senior Principal Software Engineer
> > >>> JBoss by Red Hat
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> wildfly-dev mailing list
> > >>> wildfly-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >>
> > >> --
> > >> Brian Stansberry
> > >> Manager, Senior Principal Software Engineer
> > >> JBoss by Red Hat
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> wildfly-dev mailing list
> > >> wildfly-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >>
> > >
> > > --
> > > Brian Stansberry
> > > Manager, Senior Principal Software Engineer
> > > JBoss by Red Hat
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > --
> > Brian Stansberry
> > Manager, Senior Principal Software Engineer
> > JBoss by Red Hat
> >
> >
> >
> >
> >
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161213/aca70a31/attachment-0001.html
More information about the wildfly-dev
mailing list