I draw your attention to this bit of startup code in JobTracker
try {
Thread.sleep(FS_ACCESS_RETRY_PERIOD);
} catch (InterruptedException e) {
throw new IOException("Interrupted during system directory
cleanup ",
e);
}
A few lines later, an InterruptedException is thrown directly, so
the code isn't being consistent.
-should everything at startup/shutdown time throw
InterruptedExceptions if interrupted? It would make sense, though
you have to deal with issues like Jetty, in its startup sleeps, has
code that wraps up its exceptions too:
} catch (Exception e) {
throw new IOException("Problem starting http server", e);
}
-we'd need to catch the jetty exception and look for a nested
interrupt, throw it. Ouch.
Thanks Steve for taking the time to explain this.
I guess my original email was in reference to the
TaskInputOutputContext, RecordWriter, and RecordReader classes.
for example,
The only implementation I see of RecordWriter#write() that declares
and actually throws an InterruptedException is the ChainRecordWriter
because the outputQueue is a BlockingQueue.
I just found it odd that it looked like this one class caused
InterruptedException to leak up through the new Mapper/Reducer APIs.
and looks as if it just gets eaten in Child.
cheers,
chris
--
Chris K Wensel
[email protected]
http://www.concurrentinc.com
