[
http://issues.apache.org/jira/browse/NUTCH-151?page=comments#action_12362383 ]
Paul Baclace commented on NUTCH-151:
------------------------------------
The number of threads that invoke _barrier.barrier() or .attemptBarrier()
should match the count passed to the contructor of CyclicBarrier(int), so yes,
enter the barrier before returning from PumperThread.run().
After looking at the latest Bug Parade info on avoiding resource leakage with
exec(), I think (Process).destroy() should alway be called on the way out, even
if the timeout did not occur.
That would mean:
} catch (TimeoutException ex) {
_timedout = true;
if (_destroyOnTimeout) {
proc.destroy();
}
...
if (_timedout) {
if (_destroyOnTimeout) {
proc.destroy();
}
}
becomes:
} catch (TimeoutException ex) {
_timedout = true;
...
if (_waitForExit) {
proc.destroy();
}
and field _destroyOnTimeout is removed because it is always true and/or is
subsumed by _waitForExit.
> CommandRunner can hang after the main thread exec is finished and has
> inefficient busy loop
> -------------------------------------------------------------------------------------------
>
> Key: NUTCH-151
> URL: http://issues.apache.org/jira/browse/NUTCH-151
> Project: Nutch
> Type: Bug
> Components: indexer
> Versions: 0.8-dev
> Environment: all
> Reporter: Paul Baclace
> Fix For: 0.8-dev
> Attachments: CommandRunner.060110.patch, CommandRunner.java,
> CommandRunner.java.patch
>
> I encountered a case where the JVM of a Tasktracker child did not exit after
> the main thread returned; a thread dump showed only the threads named STDOUT
> and STDERR from CommandRunner as non-daemon threads, and both were doing a
> read().
> CommandRunner usually works correctly when the subprocess is expected to be
> finished before the timeout or when no timeout is used. By _usually_, I mean
> in the absence of external thread interrupts. The busy loop that waits for
> the process to finish has a sleep that is skipped over by an exception; this
> causes the waiting main thread to compete with the subprocess in a tight loop
> and effectively reduces the available cpu by 50%.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Nutch-developers mailing list
Nutch-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nutch-developers
