[wildfly-dev] Accessing system properties in a subsystem

Mon Dec 12 16:03:02 EST 2016

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161212/a5a85557/attachment.html 