Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of pats@acm.org designates
 209.86.89.66 as permitted sender)
Message-ID: <4CEFB961.5010404@acm.org>
Date: Fri, 26 Nov 2010 05:42:57 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: QA speed improvement
References: <4CEFACEB.1010507@qcg.nl> <4CEFB5C3.2000305@acm.org>
 <4CEFB854.5010701@qcg.nl>
In-Reply-To: <4CEFB854.5010701@qcg.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sim IJskes - QCG wrote:
> On 26-11-10 14:27, Patricia Shanahan wrote:
>> Sim IJskes - QCG wrote:
>>> Suppose we have a good kill mechanism for all the testing slave VMs,
>>> would there be any harm in activating this kill mechanism during
>>> teardown? So no orderly teardown, but a brute kill.
>>
>> I see only two issues:
>>
>> 1. Making the brute kill work all the time, including reclaiming *all*
>> resources.
> 
> A self initiated System.exit(0) or better, Runtime.halt(0) should be 
> enough. I would like to check the keep-alive port mechanism, and if it 
> does not work, activate it.
> 
>> 2. Ensuring that the River features that are used during the current
>> teardown are tested in some other way.
> 
> But only if the teardown is already part of the testresult. Is it?

Whether or not a teardown failure gets reflected in the test result, we
would learn about it soon enough under current conditions, due e.g. to
non-running of subsequent tests. I suspect we do have the formal test
coverage, but I'll take a look at what teardown uses now, and check.

Patricia