4:28 a.m.
Hello,
I was looking into introducing new metrics and got into a discussion with Jeff about what
is the proper way to handle the fact that the
service is missing.
Currently if the JMSBridge is not available as a service then reading any read only
runtime attribute fails with a:
{
"outcome" => "failed",
"result" => 0,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"messaging-activemq\"),
(\"jms-bridge\" => \"test\")
]' not found",
"rolled-back" => true
}
So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)"
will fail in admin-only mode. This feels strange to me as i
would expect an "undefined" result and not a failure. In the same way, trying to
get the number of processed messages by the bridge should
return undefined since the bridge is not running. Do we have a rule so that this behaviour
is consistent ?
Cheers,
Emmanuel
4:56 a.m.
On 16 Jan 2019, at 11:28, Emmanuel Hugonnet
<ehugonne(a)redhat.com> wrote:
Hello,
I was looking into introducing new metrics and got into a discussion with Jeff about what
is the proper way to handle the fact that the
service is missing.
Currently if the JMSBridge is not available as a service then reading any read only
runtime attribute fails with a:
{
"outcome" => "failed",
"result" => 0,
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"messaging-activemq\"),
(\"jms-bridge\" => \"test\")
]' not found",
"rolled-back" => true
}
So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)"
will fail in admin-only mode. This feels strange to me as i
would expect an "undefined" result and not a failure. In the same way, trying
to get the number of processed messages by the bridge should
return undefined since the bridge is not running. Do we have a rule so that this
behaviour is consistent ?
Let’s focus on runtime attribute (and put metric aside).
My argument to Emmanuel is all about consistency. The resource (jams-bridge) has runtime
operations (start, pause) and corresponding runtime attribute (started, paused).
When the server is in admin-only, the runtime operations MUST fail (although
the reported failure description could be improved).
I argue that the read-attribute operation should behave in a consistent fashion.
When the user queries the `started` attribute, the read-attribute operation MUST fail
because the server is not in the proper stage to determine the value.
Otherwise, we end up with an attribute that can be in a 3-state (true/false/undefined).
“Undefined” means we don’t know the value of the attribute. This is not a correct response
to me. We *know* that the server is in admin-only and that the attribute value can not be
determined without the runtime, hence the failure.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
5:06 p.m.
On Wed, Jan 16, 2019 at 5:01 AM Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
> On 16 Jan 2019, at 11:28, Emmanuel Hugonnet <ehugonne(a)redhat.com> wrote:
>
> Hello,
>
> I was looking into introducing new metrics and got into a discussion
with Jeff about what is the proper way to handle the fact that the
> service is missing.
>
> Currently if the JMSBridge is not available as a service then reading
any read only runtime attribute fails with a:
>
> {
> "outcome" => "failed",
> "result" => 0,
> "failure-description" => "WFLYCTL0216: Management resource
'[
> (\"subsystem\" => \"messaging-activemq\"),
> (\"jms-bridge\" => \"test\")
> ]' not found",
> "rolled-back" => true
> }
>
> So
"/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)"
will fail in admin-only mode. This feels strange to me as i
> would expect an "undefined" result and not a failure. In the same way,
trying to get the number of processed messages by the bridge should
> return undefined since the bridge is not running. Do we have a rule so
that this behaviour is consistent ?
Let’s focus on runtime attribute (and put metric aside).
My argument to Emmanuel is all about consistency. The resource
(jams-bridge) has runtime operations (start, pause) and corresponding
runtime attribute (started, paused).
When the server is in admin-only, the runtime operations MUST fail
(although
the reported failure description could be improved).
I argue that the read-attribute operation should behave in a consistent
fashion.
When the user queries the `started` attribute, the read-attribute
operation MUST fail because the server is not in the proper stage to
determine the value.
Otherwise, we end up with an attribute that can be in a 3-state
(true/false/undefined).
“Undefined” means we don’t know the value of the attribute. This is not a
correct response to me. We *know* that the server is in admin-only and that
the attribute value can not be determined without the runtime, hence the
failure.
tl;dr; I think failing is ok, but only if it truly is a tri-state.
I'll start my reply with a bit of a tangent.
The previous discussion of this is at
http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004225.html which
got encapsulated as the requirements of
https://issues.jboss.org/browse/WFCORE-831. I don't think we should alter
any of the default behavior of metrics there.
I also know for some of your metrics subsystem work you looked at ways to
not get the WFCORE-831 undefined metric value, as you were making a request
for a specific purpose and you were prepared to deal with no value. That
seems like a good way to deal with cases where the caller doesn't want
undefined metric values.
End tangent; now to the question about non-metric runtime only attributes.
First, the requirements of section VIII of
https://issues.jboss.org/browse/WFCORE-831 apply. You can't return
'undefined' if the description doesn't say that's a possible value.
Second, stating undefined is possible and returning that is an option but
your argument about consistency with other runtime-only behavior of the
resource is valid.
Third, if an attribute already says it may return undefined and now we
change that and fail instead, that''s an API breaking change, so no good.
Fourth, failing is bad if it's reasonably avoidable. For example, if the
service for a bridge is not even installed, then it seems like that bridge
is neither started nor paused. (Apologies if I'm missing some subtlety
about a bridge.) Those attributes are arguably a tri-state but arguably
not, and it seems good to resolve such debates in the direction of not
failing. Particularly if some generic op like
:read-resource(include-runtime=true) would otherwise work for the resource.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
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
Red Hat
2148
days inactive
2148
days old
2 comments
3 participants
participants (3)
-
Brian Stansberry -
Emmanuel Hugonnet -
Jean-Frederic Mesnil