river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Build failed in Hudson: River-trunk-QA #16
Date Tue, 07 Sep 2010 11:32:23 GMT
Revision 992144 qa.run runs clean on the home system I use for development.

It has two dual-core Xeon processors, and each core is dual threaded, 
for a total of 8 hardware threads, 8GB memory. I've run the 
MulticastMonitorAllChange test both directly under WindowsXP 64-bit 
professional, and also on Ubuntu in a VirtualBox.

I've started a series of repeated runs to see if it will ever fail, and 
will report results later from a few hours of that. Is there any way we 
can force repeated runs of the one test on Hudson, to get more runs than 
we can from doing the complete QA test?

There does appear to me to be a race condition in 
ServiceDiscoveryManager's addProxyReg - the add to a TaskManager should 
be inside the synchronized block. The problem would be more likely to 
produce symptoms on a multi-core system than single core. It may be 
worth fixing it just in case it removes the Hudson failure.

However, it does not feel like a concurrency failure to me. It runs too 
solidly on most systems, and fails too solidly on Hudson. I would expect 
a concurrency issue to produce varying results in at least one of the 
environments.

Patricia






On 9/7/2010 3:33 AM, Jonathan Costers wrote:
> You check out the trunk, set the property "run.tests" in your
> <trunk>/build.properties to the tests that fail:
>
> run.tests=com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td
>
> and from<trunk>/qa/build.xml, run the "run-tests" target.
>
> This will only run the test you requested.
>
> 2010/9/7 Sim IJskes - QCG<sim@qcg.nl>
>
>> On 09/07/2010 11:44 AM, Jonathan Costers wrote:
>>
>>> What I find really strange is that I have this one test failing on Hudson,
>>> while it is passing on my machine ... (see my previous emails) I have a
>>> freshly checked out trunk ... I'm suspecting a concurrency issue of some
>>> sort.
>>>
>>
>> That my idea exactly. Singlecore vs multicore could be very important here.
>>
>>
>>   It would be very helpful if someone else could run this test locally and
>>> post the results.
>>>
>>
>> OK, i check out the trunk, and then? I only have 686 systems, multicore. I
>> could boot an old Pentium 1 with a linux system. I can run 1 or 2 processor
>> in vmware under linux.
>>
>> We can also try running a hudson slave, for a limited periode, and look how
>> much it will affect operations here.
>>
>> What do you need?
>>
>> Gr. Sim
>>
>


Mime
View raw message