2:50 p.m.
Thanks for the input/
This is the point I do not think the property has been set by:
"MSC service thread 1-3@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@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@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(a)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(a)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(a)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(a)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@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@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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev