commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siegfried Goeschl <>
Subject Re: ExecuteWatchdog does not really terminate the "hung" process?
Date Mon, 22 Jun 2009 17:19:27 GMT
Hi Ernest,

this is a lurking developer .... :-)

+) killing your top-level process has not the semantics you would expect
(see - so
under Windows it would never kill your "ping" process

+) it seems that the new ProcessBuilder does not help either (see

+) we have a test case
"DefaultExecutorTest#testExecuteAsyncWithTooLateUserTermination" which
kills a process using Watchdog - please note that we carefully avoided
to create s subprocess here since we rely on built-in shell commands -
we always try to prove that our code works ... :-)

+) which leaves the question why your thread waits for the whole 10
seconds - need to investigate that


Siegfried Goeschl

Mishkin, Ernest wrote:
> Hello,
> I have a simple test case which involves starting a .bat file which
> tries to simulate a process "stuck for N seconds" by executing
> ping -n %1 -w 1000
> I invoke this from java using DefaultExcutor, passing "10" as an
> argument to .bat file (so that it will run 10 approx. 1 sec pings
> resulting in close to 10 sec wait).
> I'm also setting ExecuteWatchdog with a 2 sec timeout.
> Problem is, my execute call does not return until ~ 10 seconds later, as
> measured by System.currentTimeMillis().
> The watchdog confirms that it "killed" the process however the expected
> behavior is that execute() call gets interrupted after 2 secs and it
> wasn't.
> The complete source code is attached. 
> Please help me understand: am I missing something fundamental, have I
> found an issue, or something else?
> If developer(s) are lurking on this list, I'd like to mention that it
> seems like when ExecuteWatchdog detects a timeout it should interrupt
> the "primary" thread (the one which runs code from
> DefaultExecutor::executeInternal, in particular the lines below:
>             try {
>                 exitValue = process.waitFor();
>             } catch (InterruptedException e) {
>                 process.destroy();
>             }
> process.waitFor() blocks, and it seems that when process.destroy() is
> called from the watchdog thread the other thread which is stuck in
> process.waitFor() is not released.
> That's why having DefaultWatchdog maintain a reference to the executor's
> thread and interrupt()'ing it might be helpful.
> Sincerely,
> Ernest Mishkin
> --------------------------------------------------------
> The information contained in this message is intended only for the recipient, and may
be a confidential attorney-client communication or may otherwise be privileged and confidential
and protected from disclosure. If the reader of this message is not the intended recipient,
or an employee or agent responsible for delivering this message to the intended recipient,
please be aware that any dissemination or copying of this communication is strictly prohibited.
If you have received this communication in error, please immediately notify us by replying
to the message and deleting it from your computer. The McGraw-Hill Companies, Inc. reserves
the right, subject to applicable local law, to monitor and review the content of any electronic
message or information sent to or from McGraw-Hill employee e-mail addresses without informing
the sender or recipient of the message.
> --------------------------------------------------------
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message