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

Jean-Frederic Mesnil jmesnil at redhat.com
Wed Jan 16 05:56:48 EST 2019



> 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.

jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/




More information about the wildfly-dev mailing list