<br><br><div class="gmail_quote">On Thu, Feb 2, 2012 at 10:36, Toby Burnett <span dir="ltr">&lt;<a href="mailto:tburnett@uw.edu" target="_blank">tburnett@uw.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">








<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">I’m a heavy user of the IPython 0.12 parallel, and have gotten some very useful help from Min.</p></div></div></blockquote><div><br></div><div>Yay! I&#39;m glad it is useful.</div><div><br></div><div>


 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">Something I have not figured out how to do, however: If an engine fails, its GUID is reported, but, having used a balanced view to assign tasks, I don’t know which task it was assigned, which would be very useful for debugging.</p>


</div></div></blockquote><div><br></div><div>Hm, this is definitely trickier than it should be.  If you try to block/get your AsyncResults, it will tell you what tasks failed by raising EngineError with info about the task and engine.  But it should be easier to find this out.  Currently, the best way is probably to use db_query:</div>

<div><br></div><div>rc.db_query(dict(engine_uuid=&lt;engine_id&gt;), keys=[&#39;msg_id&#39;, &#39;completed&#39;, &#39;result_content&#39;])</div><div><br></div><div>From which you can see which one is the first to fail with this error.</div>

<div><br></div><div>I will look into a better way to diagnose this kind of thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">


<div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Another vague request is for tools to set up, monitor, and kill a cluster. It occurs to me that the notebook interface is ideal for both understanding how to do things, and easily customizing for an individual setup: in my case the notebook
 server runs in the same environment as the engines, so a notebook is a nice way to perform cluster management.</p></div></div></blockquote><div><br></div><div>Good thing Brian is working on exactly that today :)</div><div>


 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span><font color="#888888"><u></u><u></u></font></span></p>


<span><font color="#888888">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">--Toby Burnett<u></u><u></u></p>
</font></span></div>
</div>

<br>_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org" target="_blank">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>
<br></blockquote></div><br>