[wildfly-dev] Should I fail or should I undefine ?

[Brian Stansberry]

On Wed, Jan 16, 2019 at 5:01 AM Jean-Frederic Mesnil <jmesnil at redhat.com>
wrote:

>
>
> > On 16 Jan 2019, at 11:28, Emmanuel Hugonnet <ehugonne at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190116/f6bab26d/attachment-0001.html