<div dir="ltr">Just for clarification - if we used the management HTTP server - would it be possible to expose health endpoints in Library mode? I think the library use case might be also very important.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 26, 2016 at 10:34 AM, Tristan Tarrant <span dir="ltr">&lt;<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/07/16 10:24, Sebastian Laskawiec wrote:<br>
&gt; Hey Tristan!<br>
&gt;<br>
&gt; Comments inlined.<br>
&gt;<br>
&gt; Thanks<br>
&gt; Sebastian<br>
&gt;<br>
&gt; On Tue, Jul 26, 2016 at 9:50 AM, Tristan Tarrant &lt;<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a><br>
</span><span class="">&gt; &lt;mailto:<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     On 26/07/16 07:10, Sebastian Laskawiec wrote:<br>
&gt;     &gt; Dear Community,<br>
&gt;     &gt;<br>
&gt;     &gt; I&#39;d like to ask you for help. I&#39;m currently sketching a design for a<br>
&gt;     &gt; REST health check endpoint for Infinispan and I&#39;m trying to imagine<br>
&gt;     &gt; possible use cases.<br>
&gt;     The health-check should be implemented as an MBean initially, with the<br>
&gt;     ability to expose it via alternative implementations later. The server<br>
&gt;     RESTful endpoint should be registered with the management<br>
&gt;     interface via<br>
&gt;     a special handler.<br>
&gt;<br>
&gt;<br>
&gt; Yes, I think it&#39;s a good idea. We could even use tools like Jolokia<br>
&gt; [1] to expose MBeans through REST interface (it can be added to<br>
&gt; standalone.conf to the bootstrap classpath). Alternatively we could<br>
&gt; use JDK embedded HTTP Server [2].<br>
<br>
</span>No, for server we would not use Jolokia but rely on the management HTTP<br>
server (the one that handles port 9990 already).<br>
<div><div class="h5"><br>
&gt;<br>
&gt;     A cache and cachemanager&#39;s health is determined by a combination of<br>
&gt;     parameters and we probably should allow for a user-pluggable<br>
&gt;     checker. We<br>
&gt;     already expose a number of statuses already, although obviously this<br>
&gt;     would be an aggregate.<br>
&gt;<br>
&gt;<br>
&gt; Could you please elaborate more on that? How do we expose this<br>
&gt; information? Are you referring to Infinispan Stats [3]?<br>
&gt;<br>
&gt; I also though about supporting queries somehow. An imaginary example<br>
&gt; from the top of my head could look like the following:<br>
&gt;<br>
&gt; http://$ISPN/_health?cluster.nodes=3&amp;MyCacheManager.MyCache.status=DEGRADED<br>
&gt; //&lt;-- This would return 200 OK if we have 3 nodes and given cache is<br>
&gt; in degraded mode.<br>
&gt; http://$ISPN/_health?cluster.nodes=3&amp;MyCacheManager.rebalance=IN_PROGRESS<br>
&gt; //&lt;-- Checks if we have 3 nodes and rebalance is in proress<br>
&gt;<br>
&gt; [3]<br>
&gt; <a href="https://github.com/infinispan/infinispan/tree/8.2.x/core/src/main/java/org/infinispan/stats" rel="noreferrer" target="_blank">https://github.com/infinispan/infinispan/tree/8.2.x/core/src/main/java/org/infinispan/stats</a><br>
&gt;<br>
&gt;<br>
&gt;     &gt;<br>
&gt;     &gt; Could you please give me a hand and tell me what functionalities are<br>
&gt;     &gt; important for you? Would you like to be able to check status<br>
&gt;     per-cache<br>
&gt;     &gt; or maybe a red (not healthy), green (healthy), yellow (healthy,<br>
&gt;     &gt; rebalance in progress) cluster status is sufficient? What kind of<br>
&gt;     &gt; information do you expect to be there?<br>
&gt;     I wouldn&#39;t want this to be overly complex: a simple OK, KO should be<br>
&gt;     sufficient. Additional detail may be optionally present, but not a<br>
&gt;     requirement.<br>
&gt;<br>
&gt;<br>
&gt; I think we will need at least a 3rd state - yellow or something like<br>
&gt; this. This would mean that a rebalance is in progress of a node is<br>
&gt; joining/leaving. In other words - the cluster accepts requests but<br>
&gt; don&#39;t touch the nodes!<br>
</div></div>Agreed.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tristan<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div>