commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siegfried Goeschl (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (SANDBOX-193) [exec] Watchdog "shutdown"
Date Tue, 04 Dec 2007 12:15:44 GMT

     [ 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.


Mime
View raw message