Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of pats@acm.org designates
 209.86.89.67 as permitted sender)
Message-ID: <4C71B92A.40000@acm.org>
Date: Sun, 22 Aug 2010 16:56:26 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: ServiceDiscoveryManager test coverage
References: <4C6E0F9C.5090302@acm.org> <4C6F587F.6080904@zeus.net.au>
 <4C6F60F7.2020305@acm.org> <4C6F6DD0.10407@zeus.net.au>
 <4C6FC021.5080904@acm.org> <4C6FC72E.4040907@zeus.net.au>
 <4C7016DB.2070205@acm.org> <4C70180D.2060203@acm.org>
 <4C70569F.5070203@zeus.net.au> <4C70B2E6.9000801@acm.org>
 <4C719365.6050501@acm.org>
In-Reply-To: <4C719365.6050501@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/22/2010 2:15 PM, Patricia Shanahan wrote:
> On 8/21/2010 10:17 PM, Patricia Shanahan wrote:
> ...
>> Tomorrow, unless I get a better idea or someone posts one, I'll start a
>> binary search. The objective will be to find consecutive revisions N and
>> N+1 such that N passes the servicediscovery tests and N+1 fails them.
> ...
>
> I have preliminary results from the binary search. I can't narrow it
> down to a single check-in because I cannot build revision 934802. The
> indications are that revision 934258 is the last buildable revision that
> passes and revision 935130 is the first buildable revision that fails.
>
> This is based on a single test,
> com/sun/jini/test/impl/servicediscovery/event/NotifyEventDropProxyTaskRace.td,
> that I had previously found to be solidly failing on repeated runs on
> the latest revision.
>
> I'm in the process of running the full QA tests, servicediscovery
> included, to see if the other failing tests behave the same way.

Both sets of servicediscovery tests have completed, with zero failures 
for 934258 and ten failures for 935130, confirming that the entire set 
of servicediscovery failures in the head revision should be attributed 
to the changes between those two revisions.

The failures seem to me to be too solidly reproducible, without any 
added delays, to be likely to be race conditions, even though that is 
what several of the failing tests were originally designed to demonstrate.

Patricia