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

Mime
View raw message