<div dir="ltr"><div>Ok, now I have some worker logs:<br><br><a href="http://people.cs.uchicago.edu/~tga/2014-9-4-worker-logs.tar.gz">http://people.cs.uchicago.edu/~tga/2014-9-4-worker-logs.tar.gz</a><br><br></div><div>There's nothing obvious I see in the worker logs that would indicate why the connection was broken.<br>
</div><div><br></div>- Tim<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 1:11 PM, Tim Armstrong <span dir="ltr"><<a href="mailto:tim.g.armstrong@gmail.com" target="_blank">tim.g.armstrong@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This is all running locally on my laptop, so I think we can rule out 1).<br><br>It also seems like it's a state the coaster service gets into after a few client sessions: generally the first coaster run works fine, then after a few runs the problem occurs more frequently.<br>

<br></div>I'm going to try and get worker logs, in the meantime i've got some jstacks (attached).<br><div><br>Matching service logs (largish) are here if needed:<br><a href="http://people.cs.uchicago.edu/~tga/service.out.gz" target="_blank">http://people.cs.uchicago.edu/~tga/service.out.gz</a><br>

</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 10:35 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">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">Ah, makes sense.<br>
<br>
2 minutes is the channel timeout. Each live connection is guaranteed to<br>
have some communication for any 2 minute time window, partially due to<br>
periodic heartbeats (sent every 1 minute). If no packets flow for the<br>
duration of 2 minutes, the connection is assumed broken and all jobs<br>
that were submitted to the respective workers are considered failed. So<br>
there seems to be an issue with the connections to some of the workers,<br>
and it takes 2 minutes to detect them.<br>
<br>
Since the service seems to be alive (although a jstack on the service<br>
when thing seem to hang might help), this leaves two possibilities:<br>
1 - some genuine network problem<br>
2 - the worker died without properly closing TCP connections<br>
<br>
If (2), you could enable worker logging<br>
(Settings::Key::WORKER_LOGGING_LEVEL = "DEBUG") to see if anything shows<br>
up.<br>
<span><font color="#888888"><br>
Mihael<br>
</font></span><div><div><br>
On Wed, 2014-09-03 at 20:26 -0500, Tim Armstrong wrote:<br>
> Here are client and service logs, with part of service log edited down to<br>
> be a reasonable size (I have the full thing if needed, but it was over a<br>
> gigabyte).<br>
><br>
> One relevant section is from 19:49:35 onwards.  The client submits 4 jobs<br>
> (its limit), but they don't complete until 19:51:32 or so (I can see that<br>
> one task completed based on ncompleted=1 in the check_tasks log message).<br>
> It looks like something has happened with broken pipes and workers being<br>
> lost, but I'm not sure what the ultimate cause of that is likely to be.<br>
><br>
> - Tim<br>
><br>
><br>
><br>
> On Wed, Sep 3, 2014 at 6:20 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>> wrote:<br>
><br>
> > Hi Tim,<br>
> ><br>
> > I've never seen this before with pure Java.<br>
> ><br>
> > Do you have logs from these runs?<br>
> ><br>
> > Mihael<br>
> ><br>
> > On Wed, 2014-09-03 at 16:49 -0500, Tim Armstrong wrote:<br>
> > > I'm running a test Swift/T script that submit tasks to Coasters through<br>
> > the<br>
> > > C++ client and I'm seeing some odd behaviour where task<br>
> > > submission/execution is stalling for ~2 minute periods.  For example, I'm<br>
> > > seeing submit log messages like "submitting<br>
> > > urn:133-1409778135377-1409778135378: /bin/hostname" in bursts of several<br>
> > > seconds with a gap of roughly 2 minutes in between, e.g. I'm seeing<br>
> > bursts<br>
> > > with the following intervals in my logs.<br>
> > ><br>
> > > 16:07:04,603 to 16:07:10,391<br>
> > > 16:09:07,377 to 16:09:13,076<br>
> > > 16:11:10,005 to 16:11:16,770<br>
> > > 16:13:13,291 to 16:13:19,296<br>
> > > 16:15:16,000 to 16:15:21,602<br>
> > ><br>
> > > From what I can tell, the delay is on the coaster service side: the C<br>
> > > client is just waiting for a response.<br>
> > ><br>
> > > The jobs are just being submitted through the local job manager, so I<br>
> > > wouldn't expect any delays there.  The tasks are also just<br>
> > "/bin/hostname",<br>
> > > so should return immediately.<br>
> > ><br>
> > > I'm going to continue digging into this on my own, but the 2 minute delay<br>
> > > seems like a big clue: does anyone have an idea what could cause stalls<br>
> > in<br>
> > > task submission of 2 minute duration?<br>
> > ><br>
> > > Cheers,<br>
> > > Tim<br>
> ><br>
> ><br>
> ><br>
<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>