5:39 p.m.
tl;dr
We have a minor anomaly in system property processing in domain mode
that we intend to ignore.
long version
While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
define a system-property resource in domain.xml or host.xml with
"boot-time=true", the HC does both of the following when it launches a
server:
1) Uses -D to set the prop when it starts the server process.
2) Adds an add system-property op to the server's set of boot ops, which
causes the system property to get set again later during boot.
Really, only 1) should happen; that's what "boot-time=true" means. The
purpose of boot-time=true is to ensure the value is set at JVM launch,
not waiting for management ops to execute, which may be too late for
props that are read early.
The other thing that happens is when you add such a prop to the domain
or host model, we immediately execute an add op on all relevant running
servers. This somewhat ignores a possible meaning of "boot-time=true",
which implies the prop needs to be set at boot. Since that hasn't
happened, really the server should be put into restart-required state.
But, at this point we intend to leave the behavior as is. It's been this
way for a long time and people may be unknowingly counting on the prop
being directly written and the server not going into restart-required.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:13 p.m.
On 5 Feb 2015, at 16:39, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
tl;dr
We have a minor anomaly in system property processing in domain mode
that we intend to ignore.
long version
While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
define a system-property resource in domain.xml or host.xml with
"boot-time=true", the HC does both of the following when it launches a
server:
1) Uses -D to set the prop when it starts the server process.
2) Adds an add system-property op to the server's set of boot ops, which
causes the system property to get set again later during boot.
Really, only 1) should happen; that's what "boot-time=true" means. The
purpose of boot-time=true is to ensure the value is set at JVM launch,
not waiting for management ops to execute, which may be too late for
props that are read early.
I am not 100% convinced. 1) should of course happen. But
it could be argued that something in the domain management model should always be
reflected in the resulting server management model. It feels a bit weird to make random
exceptions.
The other thing that happens is when you add such a prop to the domain
or host model, we immediately execute an add op on all relevant running
servers. This somewhat ignores a possible meaning of "boot-time=true",
which implies the prop needs to be set at boot. Since that hasn't
happened, really the server should be put into restart-required state.
But, at this point we intend to leave the behavior as is. It's been this
way for a long time and people may be unknowingly counting on the prop
being directly written and the server not going into restart-required.
+1
--
Brian Stansberry
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
6:24 p.m.
On 2/5/15 11:13 AM, Kabir Khan wrote:
> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
>
> tl;dr
>
> We have a minor anomaly in system property processing in domain mode
> that we intend to ignore.
>
> long version
>
> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
> define a system-property resource in domain.xml or host.xml with
> "boot-time=true", the HC does both of the following when it launches a
> server:
>
> 1) Uses -D to set the prop when it starts the server process.
>
> 2) Adds an add system-property op to the server's set of boot ops, which
> causes the system property to get set again later during boot.
>
> Really, only 1) should happen; that's what "boot-time=true" means. The
> purpose of boot-time=true is to ensure the value is set at JVM launch,
> not waiting for management ops to execute, which may be too late for
> props that are read early.
I am not 100% convinced.
Me neither. :)
1) should of course happen. But it could be argued that something in the
domain management model should always be reflected in the resulting
server management model. It feels a bit weird to make random exceptions.
It's similar to a jvm setting. It's a configuration of how the HC behaves.
>
> The other thing that happens is when you add such a prop to the domain
> or host model, we immediately execute an add op on all relevant running
> servers. This somewhat ignores a possible meaning of "boot-time=true",
> which implies the prop needs to be set at boot. Since that hasn't
> happened, really the server should be put into restart-required state.
>
> But, at this point we intend to leave the behavior as is. It's been this
> way for a long time and people may be unknowingly counting on the prop
> being directly written and the server not going into restart-required.
+1
>
> --
> Brian Stansberry
> 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
Senior Principal Software Engineer
JBoss by Red Hat
6:33 p.m.
On Feb 5, 2015, at 11:24 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On 2/5/15 11:13 AM, Kabir Khan wrote:
>
>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>
>> tl;dr
>>
>> We have a minor anomaly in system property processing in domain mode
>> that we intend to ignore.
>>
>> long version
>>
>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>> define a system-property resource in domain.xml or host.xml with
>> "boot-time=true", the HC does both of the following when it launches a
>> server:
>>
>> 1) Uses -D to set the prop when it starts the server process.
>>
>> 2) Adds an add system-property op to the server's set of boot ops, which
>> causes the system property to get set again later during boot.
>>
>> Really, only 1) should happen; that's what "boot-time=true" means.
The
>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>> not waiting for management ops to execute, which may be too late for
>> props that are read early.
> I am not 100% convinced.
Me neither. :)
1) should of course happen. But it could be argued that something in the
domain management model should always be reflected in the resulting
server management model. It feels a bit weird to make random exceptions.
It's similar to a jvm setting. It's a configuration of how the HC behaves.
If I understand correctly, the add op generated on all servers sets a system property,
which activates at runtime correct?
If so I actually think the behavior is arguably correct, if a bit odd.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
6:46 p.m.
On 2/5/15 11:33 AM, Jason Greene wrote:
> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>
>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>>
>>> tl;dr
>>>
>>> We have a minor anomaly in system property processing in domain mode
>>> that we intend to ignore.
>>>
>>> long version
>>>
>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>> define a system-property resource in domain.xml or host.xml with
>>> "boot-time=true", the HC does both of the following when it
launches a
>>> server:
>>>
>>> 1) Uses -D to set the prop when it starts the server process.
>>>
>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>> causes the system property to get set again later during boot.
>>>
>>> Really, only 1) should happen; that's what "boot-time=true"
means. The
>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>> not waiting for management ops to execute, which may be too late for
>>> props that are read early.
>> I am not 100% convinced.
>
> Me neither. :)
>
> 1) should of course happen. But it could be argued that something in the
> domain management model should always be reflected in the resulting
> server management model. It feels a bit weird to make random exceptions.
>
> It's similar to a jvm setting. It's a configuration of how the HC behaves.
If I understand correctly, the add op generated on all servers sets a system property,
which activates at runtime correct?
Yes, but the property has already been set, via -D when the process was
started. So it's redundant.
If so I actually think the behavior is arguably correct, if a bit
odd.
I don't see this part as much of a problem; it's just odd.
The problem is more the part you cut: when a prop gets added to the
domain model after a server is running. Say in the CLI:
/system-property=java.net.preferIPv4Address:add(value=true,boot-time=true)
Domain level scope; applicable to all servers. All servers will end up
getting this op as part of domain rollout of the change:
/system-property=java.net.preferIPv4Address:add(value=true)
Now those server JVMs will have java.net.preferIPv4Address=true
But their actual running behavior will not reflect this. The VM reads
that prop early and doesn't read it again. You need to set it at VM
launch for it to take proper effect, which is why we have the
boot-time=true attribute in the first place.
At this point the server's runtime state is out of sync with the domain
configuration, but we don't reflect that by putting the server in
restart-required.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
7:12 p.m.
On Feb 5, 2015, at 11:46 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On 2/5/15 11:33 AM, Jason Greene wrote:
>
>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>
>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>>
>>>> On 5 Feb 2015, at 16:39, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>>>>
>>>> tl;dr
>>>>
>>>> We have a minor anomaly in system property processing in domain mode
>>>> that we intend to ignore.
>>>>
>>>> long version
>>>>
>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>>> define a system-property resource in domain.xml or host.xml with
>>>> "boot-time=true", the HC does both of the following when it
launches a
>>>> server:
>>>>
>>>> 1) Uses -D to set the prop when it starts the server process.
>>>>
>>>> 2) Adds an add system-property op to the server's set of boot ops,
which
>>>> causes the system property to get set again later during boot.
>>>>
>>>> Really, only 1) should happen; that's what "boot-time=true"
means. The
>>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>>> not waiting for management ops to execute, which may be too late for
>>>> props that are read early.
>>> I am not 100% convinced.
>>
>> Me neither. :)
>>
>> 1) should of course happen. But it could be argued that something in the
>> domain management model should always be reflected in the resulting
>> server management model. It feels a bit weird to make random exceptions.
>>
>> It's similar to a jvm setting. It's a configuration of how the HC
behaves.
>
> If I understand correctly, the add op generated on all servers sets a system
property, which activates at runtime correct?
>
Yes, but the property has already been set, via -D when the process was started. So
it's redundant.
>
Well I’m talking about the case where the server is already running and has not yet
restarted. Perhaps that is why it does this?
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
7:19 p.m.
On 2/5/15 12:12 PM, Jason Greene wrote:
> On Feb 5, 2015, at 11:46 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> On 2/5/15 11:33 AM, Jason Greene wrote:
>>
>>> On Feb 5, 2015, at 11:24 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>>>
>>> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>>>
>>>>> On 5 Feb 2015, at 16:39, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
>>>>>
>>>>> tl;dr
>>>>>
>>>>> We have a minor anomaly in system property processing in domain mode
>>>>> that we intend to ignore.
>>>>>
>>>>> long version
>>>>>
>>>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When
you
>>>>> define a system-property resource in domain.xml or host.xml with
>>>>> "boot-time=true", the HC does both of the following when it
launches a
>>>>> server:
>>>>>
>>>>> 1) Uses -D to set the prop when it starts the server process.
>>>>>
>>>>> 2) Adds an add system-property op to the server's set of boot
ops, which
>>>>> causes the system property to get set again later during boot.
>>>>>
>>>>> Really, only 1) should happen; that's what
"boot-time=true" means. The
>>>>> purpose of boot-time=true is to ensure the value is set at JVM
launch,
>>>>> not waiting for management ops to execute, which may be too late for
>>>>> props that are read early.
>>>> I am not 100% convinced.
>>>
>>> Me neither. :)
>>>
>>> 1) should of course happen. But it could be argued that something in the
>>> domain management model should always be reflected in the resulting
>>> server management model. It feels a bit weird to make random exceptions.
>>>
>>> It's similar to a jvm setting. It's a configuration of how the HC
behaves.
>>
>> If I understand correctly, the add op generated on all servers sets a system
property, which activates at runtime correct?
>>
>
> Yes, but the property has already been set, via -D when the process was started. So
it's redundant.
>
>>
Well I’m talking about the case where the server is already running and has not yet
restarted. Perhaps that is why it does this?
Ah, I just noticed a detail. The default value of boot-time is true.
Which makes sense; setting the prop at VM launch is the best way.
If the default is true though, that's pretty invisible to users, who may
often want the prop set immediately when they configure it.
So, this confirms that I don't want to change this behavior.
Thanks for helping me think it through.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:51 p.m.
On 5 Feb 2015, at 17:33, Jason Greene <jason.greene(a)redhat.com>
wrote:
> On Feb 5, 2015, at 11:24 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
> On 2/5/15 11:13 AM, Kabir Khan wrote:
>>
>>> On 5 Feb 2015, at 16:39, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>>>
>>> tl;dr
>>>
>>> We have a minor anomaly in system property processing in domain mode
>>> that we intend to ignore.
>>>
>>> long version
>>>
>>> While digging into a bug Emmanuel Hugonnet noticed an anomaly. When you
>>> define a system-property resource in domain.xml or host.xml with
>>> "boot-time=true", the HC does both of the following when it
launches a
>>> server:
>>>
>>> 1) Uses -D to set the prop when it starts the server process.
>>>
>>> 2) Adds an add system-property op to the server's set of boot ops, which
>>> causes the system property to get set again later during boot.
>>>
>>> Really, only 1) should happen; that's what "boot-time=true"
means. The
>>> purpose of boot-time=true is to ensure the value is set at JVM launch,
>>> not waiting for management ops to execute, which may be too late for
>>> props that are read early.
>> I am not 100% convinced.
>
> Me neither. :)
>
> 1) should of course happen. But it could be argued that something in the
> domain management model should always be reflected in the resulting
> server management model. It feels a bit weird to make random exceptions.
>
> It's similar to a jvm setting. It's a configuration of how the HC behaves.
If I understand correctly, the add op generated on all servers sets a system property,
which activates at runtime correct?
If so I actually think the behavior is arguably correct, if a bit odd.
They will get set in its system properties, although it might be 'too late’ e.g.
-Djava.security.manager needs to be passed in at boot time (this is a bad example since
we’re moving to -secmgr but there are probably others)
Still I think this affects the whole system property idea, there could be other
non-boot-time ones which are read on subsystem startup, and affect how a subsystem
behaves. Changing those later has no effect. Or a similar example are the properties to
toggle ipv4 vs ipv6, I believe once the stack has initialised changing those doesn’t have
any effect whatsoever.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3362
days inactive
3362
days old
7 comments
3 participants
participants (3)
-
Brian Stansberry -
Jason Greene -
Kabir Khan