<br><br><div class="gmail_quote">On Sun, Feb 12, 2012 at 11:48, Darren Govoni <span dir="ltr">&lt;<a href="mailto:darren@ontrenet.com">darren@ontrenet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Sun, 2012-02-12 at 11:12 -0800, MinRK wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Feb 12, 2012 at 10:42, Darren Govoni &lt;<a href="mailto:darren@ontrenet.com">darren@ontrenet.com</a>&gt;<br>
&gt; wrote:<br>
&gt;         Thanks Min,<br>
&gt;<br>
&gt;         Is it possible to open a ticket for this capability for a<br>
&gt;         (near) future<br>
&gt;         release? It compliments that already amazing load balancing<br>
&gt;         capability.<br>
&gt;<br>
&gt;<br>
&gt; You are welcome to open an Issue.  I don&#39;t know if it will make it<br>
&gt; into one of the next few releases, but it is on my todo list.  The<br>
&gt; best way to get this sort of thing going is to start with a Pull<br>
&gt; Request.<br>
<br>
</div>Ok, I will open an issue. Thanks. In the meantime, is it possible for<br>
clients to &#39;know&#39; when a controller is no longer available? For example,<br>
it would be nice if I can insert a callback handler for this sort of<br>
internal exception so I can provide some graceful recovery options.<br></blockquote><div><br></div><div>It would be sensible to add a heartbeat mechanism on the controller-&gt;client PUB channel for this information.  Until then, your main controller crash detection is going to be simple timeouts.</div>

<div><br></div><div>ZeroMQ makes disconnect detection a challenge (because there are no disconnect events, because a disconnected channel is still valid, as the peer is allowed to just come back up).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im"><br>
&gt;<br>
&gt;<br>
&gt;         Perhaps a related but separate notion would be the ability to<br>
&gt;         have<br>
&gt;         clustered controllers for HA.<br>
&gt;<br>
&gt;<br>
&gt; I do have a model in mind for this sort of thing, though not multiple<br>
&gt; *controllers*, rather multiple Schedulers.  Our design with 0MQ would<br>
&gt; make this pretty simple (just start another scheduler, and make an<br>
&gt; extra call to socket.connect() on the Client and Engine is all that&#39;s<br>
&gt; needed), and this should allow scaling to tens of thousands of<br>
&gt; engines.<br>
<br>
</div>Yes! That&#39;s what I&#39;m after. In this cloud-scale age of computing, that<br>
would be ideal.<br>
<br>
<br>
Thanks Min.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt;         On Sun, 2012-02-12 at 08:32 -0800, Min RK wrote:<br>
&gt;         &gt; No, there is no failover mechanism.  When the controller<br>
&gt;         goes down, further requests will simply hang.  We have almost<br>
&gt;         all the information we need to bring up a new controller in<br>
&gt;         its place (restart it), in which case the Client wouldn&#39;t even<br>
&gt;         need to know that it went down, and would continue to just<br>
&gt;         work, thanks to some zeromq magic.<br>
&gt;         &gt;<br>
&gt;         &gt; -MinRK<br>
&gt;         &gt;<br>
&gt;         &gt; On Feb 12, 2012, at 5:02, Darren Govoni<br>
&gt;         &lt;<a href="mailto:darren@ontrenet.com">darren@ontrenet.com</a>&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt; &gt; Hi,<br>
&gt;         &gt; &gt;  Does ipython support any kind of clustering or failover<br>
&gt;         for<br>
&gt;         &gt; &gt; ipcontrollers? I&#39;m wondering how situations are handled<br>
&gt;         where a<br>
&gt;         &gt; &gt; controller goes down when a client needs to perform<br>
&gt;         something.<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; thanks for any tips.<br>
&gt;         &gt; &gt; Darren<br>
&gt;         &gt; &gt;<br>
&gt;         &gt; &gt; _______________________________________________<br>
&gt;         &gt; &gt; IPython-User mailing list<br>
&gt;         &gt; &gt; <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
&gt;         &gt; &gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
&gt;         &gt; _______________________________________________<br>
&gt;         &gt; IPython-User mailing list<br>
&gt;         &gt; <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
&gt;         &gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
&gt;<br>
&gt;<br>
&gt;         _______________________________________________<br>
&gt;         IPython-User mailing list<br>
&gt;         <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
&gt;         <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; IPython-User mailing list<br>
&gt; <a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
&gt; <a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br>
<br>
_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
</div></div></blockquote></div><br>