Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: Knut Anders Hatlen <knut.hatlen@oracle.com>
To: <derby-dev@db.apache.org>
Subject: Re: SpawnedProcess arguments and behavior
References: <4F33A1E4.7040201@oracle.com>
Mail-Copies-To: never
Mail-Followup-To: <derby-dev@db.apache.org>
Date: Thu, 09 Feb 2012 13:01:33 +0100
In-Reply-To: <4F33A1E4.7040201@oracle.com> (Kristian Waagan's message of "Thu,
	09 Feb 2012 11:37:24 +0100")
Message-ID: <wjo84nv0qkpu.fsf@oracle.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain

Kristian Waagan <kristian.waagan@oracle.com> writes:

> Hi,
>
> I've been looking a bit at SpawnProcess, and I'm planning to do some
> changes to it. The most important change is make
> BaseTestCase.readProcessOutput use the class, since reading the output
> from the subprocess requires extra code that should be isolated to one
> location. There is reason to believe a problem with readProcessOutput
> is the cause of the interrupt-related errors reported recently by
> Myrna and, possibly, Kathey.
>
> What's troubling me are the arguments destroy and timeout, especially
> the combination of the two.
> For me, a timeout implies destroy == true. Specifying a timeout and
> setting destroy to false is effectively the same as setting destroy to
> true, since destroy will be forced to true when a timeout occurs.

Agreed. I think the use case is to be able to forcefully quit a process
immediately (it's used this way only in NetworkServerTestSetup, I
think). We probably need to preserve that functionality, but it's
probably less confusing if we have one method for immediate destruction
(with no parameters) and one with a timeout (and no destroy parameter).

> For automated test runs it would be best if complete() always returns,
> although many test framworks have mechanisms to kill the main process
> if it takes too long. For debugging it may be best to keep the
> subprocess running and the main process hanging to allow for
> inspection. I think it should be possible to obtain the stack (java
> stack or native stack) of the subprocess, then kill it manually to get
> stdout/stderr and have the main process continue.
>
> I'd prefer to settle on one of two approaches, since that would
> simplify the code and define a consistent behavior:
>  a) Never destroy the process.
>  b) Always destroy the process if hanging for more than a default
> amount of time.
>
> Opinions?

Option a is of course the easier one to implement. Is it possible to get
the stack of the sub-process in a portable way with option b?

If I understand correctly, the suggestion is to always have a timeout
when calling complete(), right? That sounds reasonable to me, provided
that the timeout is high enough to avoid errors when the termination of
the sub-process just happens to be slow.

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.

-- 
Knut Anders