I enabled some more logging for the QA harness, here is the full log for the
failing test:
https://hudson.apache.org/hudson/job/River-trunk-QA/ws/jtsk/trunk/qa/result/com_sun_jini_test_spec_lookupdiscovery_MulticastMonitorAllChange.td.txt
The relevant section:
BaseQATest.waitForDiscovery FINE: events expected (3) == events
received (3), all locators equal
BaseQATest.waitForDiscovery FINE: DISCOVERY wait period complete
BaseQATest.waitForDiscovery FINE: 3 discovery event(s) expected, 3
discovery event(s) received
BaseQATest.replaceMemberGroups FINE: lookup service 0 - replacing
member groups with --
BaseQATest.replaceMemberGroups FINE: newGroups[0] =
LDGroup0_A_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[1] =
LDGroup0_B_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[2] =
LDGroup0_C_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: lookup service 1 - replacing
member groups with --
BaseQATest.replaceMemberGroups FINE: newGroups[0] =
LDGroup2_A_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[1] =
LDGroup2_B_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[2] =
LDGroup2_C_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: lookup service 2 - replacing
member groups with --
BaseQATest.replaceMemberGroups FINE: newGroups[0] =
LDGroup1_A_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[1] =
LDGroup1_B_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[2] =
LDGroup1_C_hudson_solaris_1283506469271_new
BaseQATest.replaceMemberGroups FINE: newGroups[3] =
LDGroup1_D_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: for CHANGE events -- waiting at least
30 seconds, but no more than 900 seconds ...
TIME: 9:35:31 AM
BaseQATest.waitForChange FINE: initial wait period complete ...
waiting at most 870 more seconds ...
BaseQATest.waitForChange FINE: changedMap.size == 0
BaseQATest.waitForChange FINE: expectedChangedMap.size == 3
BaseQATest.waitForChange FINE: expectedChangedMap.locator =
ConstrainableLookupLocator[[jini://hudson_solaris:58101/], [null]]
BaseQATest.waitForChange FINE: expectedChangedMap.groups[0] ==
LDGroup2_A_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[1] ==
LDGroup2_B_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[2] ==
LDGroup2_C_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.locator =
ConstrainableLookupLocator[[jini://hudson_solaris:58098/], [null]]
BaseQATest.waitForChange FINE: expectedChangedMap.groups[0] ==
LDGroup1_A_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[1] ==
LDGroup1_B_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[2] ==
LDGroup1_C_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[3] ==
LDGroup1_D_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.locator =
ConstrainableLookupLocator[[jini://hudson_solaris/], [null]]
BaseQATest.waitForChange FINE: expectedChangedMap.groups[0] ==
LDGroup0_A_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[1] ==
LDGroup0_B_hudson_solaris_1283506469271_new
BaseQATest.waitForChange FINE: expectedChangedMap.groups[2] ==
LDGroup0_C_hudson_solaris_1283506469271_new
TIME: 9:50:09 AM
BaseQATest.waitForChange FINE: events expected (3) != events received (0)
BaseQATest.waitForChange FINE: CHANGE wait period complete
com.sun.jini.qa.harness.TestException: change failed -- waited 870
seconds (14 minutes) -- 3 change event(s) expected, 0 change event(s)
received
at com.sun.jini.test.share.BaseQATest.waitForChange(Unknown Source)
at
com.sun.jini.test.spec.lookupdiscovery.MulticastMonitorChange.run(Unknown
Source)
at com.sun.jini.qa.harness.MasterTest.doTest(Unknown Source)
at com.sun.jini.qa.harness.MasterTest.main(Unknown Source)
So there seems to be a failure receiving the expected discovery change
events (obviously).
I'll look into this asap, I won't have much time this weekend though.
2010/9/3 Peter Firmstone <[email protected]>
> Thanks for the compliment.
>
> I'm looking forward to having some help, programming alone isn't much fun,
> I've been quite busy, so a short break to let others show off their skills
> while I get some much needed rest is all good.
>
> This is probably also a very good opportunity to finally get some much
> needed peer review.
>
> Welcome aboard,
>
> Peter.
>
> N.B. I'd probably break the work up into three items:
>
> 1. Concurrent policy providers. - should be an easy quick merge.
> 2. RevokeableDynamicPolicy and Security delegates. - experimental,
> this could take some time, how to avoid divergence? Can we merge
> trunk into skunk periodically to keep it up to date?
> 3. StreamingServiceRegistrar, delayed unmarshalling and maven
> provisioning support - this really needs everybody's input, it's a
> core change we'll have to live with for a long time.
>
>
>
> Patricia Shanahan wrote:
>
>> Peter Firmstone wrote:
>>
>>> Well I must say the recent participation is very encouraging, this
>>> project had a record number of emails to the development mailing list last
>>> month, but I don't come from a Programming background, I'm not an expert and
>>> don't have any merging experience.
>>>
>>
>> Regardless of whether you have formal programming education, you seem to
>> me to be a very talented and capable programmer. Organization of complex
>> multi-person software projects is a different subject.
>>
>> Checking everything directly into the trunk works well on a reasonably
>> small single person project, but I do not think it is a good plan for River
>> with multiple active developers.
>>
>> Therefore in this case I'd prefer to observe rather than vote for any
>>> particular methodology or risk letting my own wants or ego stand in the way
>>> of what River needs, which is increasing participation and innovation.
>>>
>>> I have no objections to you reverting the changes.
>>>
>>
>> For what it is worth, I strongly agree with the plan Jonathan proposes.
>>
>> I would like to get ASAP to a head trunk revision that runs all known
>> tests, then spawn off at least one branch for your work, possibly more than
>> one if it splits into separate threads that you want to push in parallel,
>> and a NewTaskManager branch with a solid basis. I hope Jonathan will
>> continue the excellent work he is doing on getting the tests organized and
>> running regularly.
>>
>> Like you, I need to learn branching and merging in SVN. I've done it in
>> other revision control systems, and the general idea is hand merging only
>> for those files that have been modified since your branch was spawned off.
>>
>> Perhaps someone can recommend a tutorial that covers SVN the way it is
>> used in Apache?
>>
>> Also, maybe we should do some branching and merging in the skunk area to
>> build confidence that we can do it right, and familiarity with what happens
>> during a merge.
>>
>> I expect that you'll continue participating and perhaps blaze the trail
>>> as leading developers, so that I can watch and learn, I'm interested to see
>>> what you have in mind.
>>>
>>> River needs people willing to do the leg work necessary to succeed.
>>>
>>
>> Agreed.
>>
>>
>>> Best Regards,
>>>
>>> Peter.
>>>
>>> Jonathan Costers wrote:
>>>
>>>> I have to agree with Sim here ...
>>>>
>>>> I'd say (if it were entirely up to me):
>>>> 1. backout the changes
>>>> 2. make sure the current QA tests run
>>>> 3. add categories servicediscovery,discoveryservice,io and security to
>>>> the
>>>> QA test categories to run by Hudson, one by one
>>>> 4. make sure these QA tests run as well
>>>> 5. piece by piece, restore the changes and keep an eye on any tests
>>>> failing.
>>>> In parallel, keep validating and adding more QA test categories.
>>>>
>>>> This would allow us to work in a more structured manner, and to perform
>>>> peer
>>>> reviews on bite size changes.
>>>> We have to better organize ourselves, considering the limited resources
>>>> we
>>>> have.
>>>>
>>>> To summarize:
>>>> - the changes to RemoteEvent etc. caused many discovery related tests to
>>>> fail
>>>> - the changes to ClassLoading caused some classloading / io related
>>>> tests to
>>>> fail
>>>> - the changes to DynamicPolicyProvider caused security (and other) tests
>>>> to
>>>> fail
>>>>
>>>> And that's what I found after going through it very quickly and backing
>>>> out
>>>> some obvious things.
>>>> These actually look more like experiments than actual tested changes.
>>>> IMO, this kind of experimentation should probably be done in a skunk
>>>> branch,
>>>> not the trunk.
>>>>
>>>> If for any reason, my understanding is incorrect, and backing out is not
>>>> an
>>>> option, then I would suggest to at least create a JIRA issue for each of
>>>> the
>>>> above topics.
>>>>
>>>> Thanks
>>>> Jonathan
>>>>
>>>> 2010/9/1 Peter Firmstone <[email protected]>
>>>>
>>>>
>>>>
>>>>> Sim IJskes - QCG wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 09/01/2010 01:16 AM, Jonathan Costers wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Similarly, having backed out the RemoteEvent changes, and running the
>>>>>>> "discoveryservice" category:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> It looks to me, that the code in the trunk was not completely ready.
>>>>>>
>>>>>>
>>>>>>
>>>>> It looks that way.
>>>>>
>>>>>
>>>>> Would it be a good idea to revert the changes until the unit tests run
>>>>>
>>>>>
>>>>>> again, and build a branch in svn to continue the work?
>>>>>>
>>>>>>
>>>>>>
>>>>> Let me get my head around understanding the failures first before we
>>>>> revert.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> If a committer (with svn access) needs help, i can offer some
>>>>>> assistance.
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks ;) much appreciated.
>>>>>
>>>>>
>>>>>
>>>>>> Gr. Sim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
