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


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


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat