<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Jan 9, 2013, at 15:26, Darren Govoni &lt;<a href="mailto:darren@ontrenet.com">darren@ontrenet.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  
    <div class="moz-cite-prefix">Min,<br>
      &nbsp;&nbsp; Thanks for this. It's a good step for system wide fault
      tolerance. For now, verifying job completion and resubmitting
      unfinished items can be managed at application layer. Perhaps down
      the road, the internal scheduler can be made persistent using, for
      example, mongo such that any un-ackd work can resume gracefully.<br></div></div></blockquote><div><br></div><div>indeed - the Hub already uses mongo to persist tasks, so all the information is there.</div><div><br></div><br><blockquote type="cite"><div><div class="moz-cite-prefix">
      <br>
      Darren<br>
      <br>
      On 01/09/2013 05:05 PM, MinRK wrote:<br>
    </div>
    <blockquote cite="mid:CAHNn8BVe+EyUx0PPqfTXpo5+G9N4N6+X6bGUdmpRUbwD8_tR7A@mail.gmail.com" type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <br>
      <br>
      <div class="gmail_quote">On Wed, Jan 9, 2013 at 10:36 AM, Min RK <span dir="ltr">&lt;<a moz-do-not-send="true" href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote">
          <div dir="auto">
            <div>Yes, there is a preliminary implementation of this in
              current master.<br>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Sorry, I should have probably mentioned exactly how you
          would do this :)</div>
        <div>
          <br>
        </div>
        <div>There are a few changes.</div>
        <div><br>
        </div>
        <div>1. if you do not set `reuse_files=True`, the controller
          will cleanup its connection files on a clean exit. &nbsp;That means
          that if you wish to stop and restart the controller cleanly,
          you need to set this (crash will generally prevent cleanup).</div>
        <div>2. engines now have their own heartbeat mechanism, so if
          the controller is down for too long, they will give up
          themselves.</div>
        <div>The logic here is a maximum number of missed heartbeats,</div>
        <div>so the timeout for engines is
          EngineFactory.max_heartbeat_misses * HeartMonitor.period
          (default = 50 * 3 ~= 3 minutes). &nbsp;You may want to change these
          two config values if that's not an appropriate time for
          engines to give up.</div>
        <div>3. to attempt to restore the controller state, do</div>
        <div>&nbsp; &nbsp; ipcontroller --restore</div>
        <div>&nbsp;</div>
        <div>I doubt that this has been tested out in the world, but I
          have played with stopping and starting the Controller myself.
          &nbsp;Note that, at present, this only re-establishes connections,
          it does not restore job queues or anything, so it is of
          limited utility.</div>
        <div><br>
        </div>
        <div>-MinRK</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote">
          <div dir="auto">
            <div><br>
              <br>
            </div>
            <div>
              <div class="h5">
                <div><br>
                  On Jan 9, 2013, at 5:50, "Darren Govoni" &lt;<a moz-do-not-send="true" href="mailto:darren@ontrenet.com" target="_blank">darren@ontrenet.com</a>&gt;
                  wrote:<br>
                  <br>
                </div>
                <blockquote type="cite">
                  <div>
                    <p>Hi,<br>
                      &nbsp;&nbsp; A good while ago I was asking if iPython could
                      reform its network after a controller restart and
                      Min was gracious enough to make a patch prototype
                      to persist the controller state towards this end.</p>
                    <p>&nbsp;&nbsp; Does the current (or next) release of iPython
                      support controller faults/restarts like this and
                      restablish engine connections on restart?</p>
                    <p>thanks,<br>
                      Darren</p>
                  </div>
                </blockquote>
              </div>
            </div>
            <blockquote type="cite">
              <div><span>_______________________________________________</span><br>
                <span>IPython-User mailing list</span><br>
                <span><a moz-do-not-send="true" href="mailto:IPython-User@scipy.org" target="_blank">IPython-User@scipy.org</a></span><br>
                <span><a moz-do-not-send="true" href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a></span><br>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
IPython-User mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a>
<a class="moz-txt-link-freetext" href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a>
</pre>
    </blockquote>
    <br>
  

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>IPython-User mailing list</span><br><span><a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a></span><br><span><a href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a></span><br></div></blockquote></body></html>