[wildfly-dev] Accessing system properties in a subsystem

Mon Dec 12 16:19:35 EST 2016

> On Dec 12, 2016, at 3:03 PM, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:
> 
> You are adding and starting this service in performBoottime which is causing you this issues.
> As you service can get started before stage MODEL can complete

performBoottime executes in Stage.RUNTIME, so it’s after MODEL.

It’s just the equivalent to performRuntime for add handlers that can only do runtime stuff during boot.

> 
> I would change initial state of the service to ON_DEMAND instead of active.
> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemAdd.java#L432
> 
> which should solve your problem. I would do the same also for JTAEnvironmentBeanService.
> 
> so they get started only when needed not up front without any requirement.
> 
> --
> tomaz
> 
> On Mon, Dec 12, 2016 at 9: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
> 
> 
> _______________________________________________
> 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