Mihael,<div><br></div><div>Have you just changed the <a href="http://worker.pl">worker.pl</a>. Asking since I am using a mix of trunk and 0.93.</div><div><br></div><div><a href="http://worker.pl">worker.pl</a> that I am using is 0.93 .. If only this is changed. I will use it from trunk.<br>
<br></div><div><br><div class="gmail_quote">On Mon, Sep 12, 2011 at 1:56 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>></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 Mon, 2011-09-12 at 11:58 -0500, Ketan Maheshwari wrote:<br>
<br>
> After some discussion with Mike, Our conclusion from these runs was<br>
> that the parallel data transfers are causing timeouts from the<br>
> <a href="http://worker.pl" target="_blank">worker.pl</a>, further, we were undecided if somehow the timeout threshold<br>
> is set too agressive plus how are they determined and whether a change<br>
> in that value could resolve the issue.<br>
<br>
</div>Something like that. Worker.pl would use the time when a file transfer<br>
started to determine timeouts. This is undesirable. The purpose of<br>
timeouts is to determine whether the other side has stopped from<br>
properly following the flow of things. It follows that any kind of<br>
activity should reset the timeout... timer.<br>
<br>
I updated the worker code to deal with the issue in a proper way. But<br>
now I need your help. This is perl code, and it needs testing.<br>
<br>
So can you re-run, first with some simple test that uses coaster staging<br>
(just to make sure I didn't mess something up), and then the version of<br>
your tests that was most likely to fail?<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Ketan<br><br><br>
</div>