river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Next steps after 2.2.1 release
Date Sun, 07 Apr 2013 11:43:52 GMT
I've attached an example of concurrency test failure, logging is 
switched off, but it doesn't tell you much if it is.

Looking at the profiler output, RetryTask.run() is called 66 times, I 
don't know how many time the tasks are retry'd.  I'm very suspicious of 
RetryTask based on Patricia's comments.

Cheers,

Peter.



Peter Firmstone wrote:
> Oh, hang on, are you developing on Windows?  If so, it's not supported 
> in 2.2.0.
>
> Peter Firmstone wrote:
>> Greg,
>>
>> You need to spend some more time figuring out why those tests are 
>> failing, that isn't normal, when 280 tests fail, there's usually 
>> something wrong with configuration.  The qa test suite just isn't 
>> that brittle ;)   The tests that fail due to concurrency errors don't 
>> fail often, we're talking 3/10 you might get a failure (if you're 
>> lucky) and likely, you won't see any failures on single core 
>> hardware.  The Jenkins tests tend to be more likely to fail because 
>> they run concurrent with other builds, in a busy network environment 
>> (sockets in use etc), with lots of superfluous discovery processes 
>> going in the background.
>>
>> If you need some help with the source tree, I'm quite familiar with 
>> it, don't be afraid to ask questions.
>>
>> This is a big distribution, there is a lot of code, it is initially 
>> difficult to find your way around, but patience will be rewarded.
>>
>> There are 3 test suites:
>>
>> 1. trunk/test
>> 2. trunk/qa/src
>> 3. trunk/qa/jtreg
>>
>> The first is the junit test suite, the second is the qa integration 
>> test suite and tck, which simulates a network environment with all 
>> the services, the last is the jtreg regression test suite.
>>
>> When you've done further investigation and better understand the 
>> code, then we'll be in a better position for discussion, right now 
>> the immediate focus should be on a 2.2.1 release.
>>
>> I'll switch to your branch and run the tests if you like.
>>
>> I'd also like to encourage you to look at the code in 
>> skunk/qa-refactoring, it's well documented and should be easy to 
>> read, I've followed Kent Beck's recommendations for code readability.
>>
>> I hope this helps.
>>
>> Regards,
>>
>> Peter.
>>
>>
>> Greg Trasuk wrote:
>>> OK, so in my last message I talked about how (speaking only for 
>>> myself) I'm a little nervous about the state of the trunk.
>>>
>>> So what now? Problems we need to avoid in this discussion:
>>> -------------------------------------------------------------
>>>
>>> - Conflation of source tree structure issues with build tool selection.
>>> - Conflation of Maven build, Maven as codebase provider (artifact 
>>> urls), and posting artifacts to Maven Central
>>> - Wish lists of pet features
>>> - Bruised egos and personal criticisms.
>>>
>>> Issues I see, in no particular order:
>>> ----------------------------------------------
>>> - We've done changes both to the test framework and the code, and 
>>> lots of them.  We should do one or the other, or small amounts of 
>>> coevolution, if absolutely necessary.
>>> - Really, I'd like to see a completely separate integration test, 
>>> and have the TCK tests separated out again.
>>> - The source tree is incomprehensible
>>> - The tests appear to be awfully sensitive to their environment.  
>>> Insofar as when I run them locally on an untouched source tree, I 
>>> get 280 failures.
>>> - There have been changes to class loading and security subsystems.  
>>> These subsystems are core to Jini, and the changes were made to the 
>>> existing source, so there's no way to "opt-out" of the changes.  I'd 
>>> like to see radical changes be optional until proven in the field, 
>>> where possible.  In the case of policy providers and class loaders, 
>>> that should be easy to do.
>>> - Similarly, it seems there have been some changes to the JERI 
>>> framework.
>>> - There are ".jar" files in our repository.  I'll stipulate that the 
>>> licensing has been checked, but it smells bad.
>>>
>>> Discussion
>>> -----------------
>>> I guess the biggest thing I'd like to see is stability in the test 
>>> framework.  Perhaps it needs refactoring or reorganization, but if 
>>> so, we need to be very careful to separate it from changes to the 
>>> core functionality.
>>>
>>> Next, I'd like for it to be easier to comprehend the source tree.  I 
>>> think a good way to do that is to separate out (carefully) the core 
>>> Jini package (basically the contents of jsk-platform.jar) and the 
>>> service implementations.  There's no reason that we have to have one 
>>> huge everything-but-the-kitchen-sink distribution.  That's just a 
>>> holdover from how Sun structured the JTSK - It was literally a 
>>> "starter kit".  To me it would be fine to have separate deliverables 
>>> for the platform and the services.
>>>
>>> While we're separating out the services, it might also be a decent 
>>> time to implement Maven-based builds if we think that's a good 
>>> idea.  I'd start with Reggie.  It would also be a good time to get 
>>> rid of the "com.sun.jini" packages.
>>>
>>> Aside:  I'm personally ambivalent on Maven (which is to say I'm 
>>> nowhere near as negative on it as I once was).  I do agree with 
>>> Dennis, though, that the jars and appropriate poms need to be 
>>> published to Maven Central.  There's no doubt that users will 
>>> appreciate that.
>>>
>>> Once we have a stable set of regression tests, then OK, we could 
>>> think about improving performance or using Maven repositories as the 
>>> codebase server.
>>>
>>> I realize this won't be popular, but my gut feel is that we need to 
>>> step back to the 2.2 branch and retrace our steps a little, and go 
>>> through the evolution again in a more measured fashion.
>>>
>>> Proposal
>>> ------------
>>>
>>> 1 - Release version 2.2.1 from the 2.2 branch.
>>> 2 - Create a separate source tree for the test framework.  This 
>>> could come from the "qa_refactor" branch, but the goal should be to 
>>> successfully test the 2.2.1 release.  Plus it should be a no-brainer 
>>> to pull it down and run it on a local machine.
>>> 3 - Release 2.2.2 from the pruned jtsk tree.  Release 1.0.0 of the 
>>> test framework.
>>> 4 - Pull out the infrastructure service implementations (Reggie, 
>>> Outrigger, Norm, etc) from the core into separate products.  Release 
>>> 1.0.0 on each of them.  Release 2.2.3 from the pruned jtsk tree.
>>> 5 - Adopt a fixed release cycle.  Not sure if it should be quarterly 
>>> or biennial, or whether it should be all products at once or 
>>> staggered releases.  We'll need to discuss.
>>> 6 - Then we can start making changes if necessary to the individual 
>>> products.  And also try to deal with making it easier for new users 
>>> to use the technology.
>>>
>>> So there you go.  Opinions?
>>>
>>> Greg Trasuk.
>>>
>>>
>>>
>>>   
>>
>>
>
>


Mime
View raw message