db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: SpawnedProcess arguments and behavior
Date Fri, 10 Feb 2012 10:16:51 GMT
Kristian Waagan <kristian.waagan@oracle.com> writes:

> On 09.02.2012 13:01, Knut Anders Hatlen wrote:
>> However, I think most of the times we've seen hangs involving
>> sub-processes, they've been caused by some kind of deadlock in the
>> communication between the main test process and the sub-process
>> (typically both processes waiting for output from the other one). In
>> those cases, the test never gets as far as to calling complete(), and a
>> timeout in complete() wouldn't help.
>> To address those cases, SpawnedProcess might need a timeout mechanism
>> that automatically destroys the process if it has lived too long. But
>> then the default timeout must be very high, since it must account for
>> the time it takes to run the test case, not just the time it takes to
>> shutdown the process after completion of the test, and we don't want the
>> timeout to cause problems on slow machines.
> This is definitely taking things a step further :)

I'm not saying we should do it. Hangs caused by test sub-processes don't
happen often enough in my environment to bother me... :)

> I think this can also be done using a timer-task. As you note, the
> difficult thing is to get the timeout right. Again, a reasonable
> default timeout may be sufficient.  Controlling this for the
> NetworkServerControlTestSetup may be a bit more of a hassle (unless
> you're okay with having loads of arguments in the method signatures),
> but since this is a safety-net feature a default timeout of 45 - 60
> minutes would hopefully be enough...
> Are we looking at something like this? (Y much smaller than X)
>  o new SpawnedProcess(...)
>     creates watchdog thread killing the process after X minutes
>  o complete()
>     waits Y minutes for the process to terminate normally, then kill
> it. Should return soon after the process terminates.
>     (active wait with sleep, or waitFor + a separate thread for
> killing the process)

(I prefer active wait with sleep here. The fewer threads, the better...)

>  o destroy()
>     kills the process immediately
>     (not sure if this is really needed, or if complete() will suffice)

Something like this, yes. Plus logic to stop the watchdog thread when
the process terminates normally.

Knut Anders

View raw message