You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Siegfried Goeschl (JIRA)" <ji...@apache.org> on 2007/12/04 13:15:44 UTC

[jira] Resolved: (SANDBOX-193) [exec] Watchdog "shutdown"

     [ https://issues.apache.org/jira/browse/SANDBOX-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Siegfried Goeschl resolved SANDBOX-193.
---------------------------------------

    Resolution: Fixed

Added an ExecuteWatchdog.destroyProcess() including regression tests

> [exec] Watchdog "shutdown"
> --------------------------
>
>                 Key: SANDBOX-193
>                 URL: https://issues.apache.org/jira/browse/SANDBOX-193
>             Project: Commons Sandbox
>          Issue Type: Improvement
>          Components: Exec
>            Reporter: Reinhold Füreder
>            Assignee: Siegfried Goeschl
>             Fix For: Nightly Builds
>
>
> In my unit tests I use apache commons exec in combination with the execution watchdog for running some (Java) processes. By default, the processes should end normally. However, in case of an error the processes might still be running so I'd like to shut them down in the tearDown() cleanup step of the test case. In order to avoid modifying apache commons exec this is currently implemented like:
> 	@Override
> 	protected void tearDown() throws Exception {
> 	    ...
> 		// This will implicitely lead to the required Process.destroy() call in case the process has not yet exited:
> 		watchdog.timeoutOccured(new Watchdog(1));
> 		watchdog.stop();
> 		...
> 	}
> There are two issues:
> (1) At least in the current implementation there does not seem to be any reason anymore for the dummy watchdog argument in the timeoutOccured() method. Should we remove that? Of course this would also mean to remove it from the corresponding TimeoutObserver interface method. On the other hand, it removes some of the flexibility in case e.g. one extends the ExecuteWatchdog and requires more than one watchdog or so...
> (2) If this kind of watchdog "shutdown" (is there a better name?) is generally useful, shall we introduce an explicit method for it in the Watchdog class itself?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.