<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 5:01 AM Jean-Frederic Mesnil <<a href="mailto:jmesnil@redhat.com">jmesnil@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 16 Jan 2019, at 11:28, Emmanuel Hugonnet <<a href="mailto:ehugonne@redhat.com" target="_blank">ehugonne@redhat.com</a>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> 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<br>
> service is missing.<br>
> <br>
> Currently if the JMSBridge is not available as a service then reading any read only runtime attribute fails with a:<br>
> <br>
> {<br>
> "outcome" => "failed",<br>
> "result" => 0,<br>
> "failure-description" => "WFLYCTL0216: Management resource '[<br>
> (\"subsystem\" => \"messaging-activemq\"),<br>
> (\"jms-bridge\" => \"test\")<br>
> ]' not found",<br>
> "rolled-back" => true<br>
> }<br>
> <br>
> So "/subsystem=messaging-activemq/jms-bridge=test:read-attribute(name=started)" will fail in admin-only mode. This feels strange to me as i<br>
> 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<br>
> return undefined since the bridge is not running. Do we have a rule so that this behaviour is consistent ?<br>
<br>
Let’s focus on runtime attribute (and put metric aside).<br>
<br>
My argument to Emmanuel is all about consistency. The resource (jams-bridge) has runtime operations (start, pause) and corresponding runtime attribute (started, paused).<br>
<br>
When the server is in admin-only, the runtime operations MUST fail (although<br>
the reported failure description could be improved).<br>
<br>
I argue that the read-attribute operation should behave in a consistent fashion.<br>
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.<br>
Otherwise, we end up with an attribute that can be in a 3-state (true/false/undefined).<br>
“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.<br>
<br></blockquote><div><span style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span style="font-family:"trebuchet ms",sans-serif">tl;dr; I think failing is ok, but only if it truly is a tri-state.</span><span style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I'll start my reply with a bit of a tangent.</span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></span>The previous discussion of this is at <a href="http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004225.html">http://lists.jboss.org/pipermail/wildfly-dev/2015-July/004225.html</a> which got encapsulated as the</span> <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">requirements of <a href="https://issues.jboss.org/browse/WFCORE-831">https://issues.jboss.org/browse/WFCORE-831</a>. I don't think we should alter any of the default behavior of metrics there.</span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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.</span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">End tangent; now to the question about non-metric runtime only attributes.</span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">First, the requirements of section </span><span style="color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px">VIII<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> of </span></span><span style="font-family:"trebuchet ms",sans-serif"><a href="https://issues.jboss.org/browse/WFCORE-831">https://issues.jboss.org/browse/WFCORE-831</a><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> apply. You can't return 'undefined' if the description doesn't say that's a possible value.</span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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.</span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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.</span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></span></span></div><div><span style="font-family:"trebuchet ms",sans-serif"><span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">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. </span></span><span style="font-family:"trebuchet ms",sans-serif">(Apologies if I'm missing some subtlety about a bridge.)<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif"> </span></span><span style="font-family:"trebuchet ms",sans-serif">Those attributes are arguably a tri-state but arguably not, and it seems good to <span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">resolve such debates</span> in the direction of not failing. Particular<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">ly</span> if some generic op like :read-resource(include-runtime=<span class="gmail_default" style="font-family:"trebuchet ms",sans-serif">true) would otherwise work for the resource.</span></span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
jeff<br>
<br>
--<br>
Jeff Mesnil<br>
JBoss, a division of Red Hat<br>
<a href="http://jmesnil.net/" rel="noreferrer" target="_blank">http://jmesnil.net/</a><br>
<br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div></div>