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: TaskManager progress
Date Sat, 31 Jul 2010 22:24:47 GMT
Hi Patricia,

I've run the second round of qa harness tests, no hits, I'll upload the 
results shortly.

jtreg tests are underway.

The qa harness (over 400 tests) is more comprehensive than the jtreg 
tests (130 + tests)

Tests can be broken down into three groups:

QA Test Harness - Integration test suite to test the Jini Specification 
behaviour and implementation.
JTReg Tests - Bug Regression Tests and more complex unit tests.
JUnit Tests - Simple Unit tests, for fast feedback at the class design 

To get all these tests functioning on Windows, I suggest we attempt 
using the make build, this might give us some insight into some of the 
platform support problems.  Try both the qa tests and the jtreg tests if 
you can.

The make test suite is available at:

svn checkout http://svn.apache.org/repos/asf/incubator/river/qatests



Patricia Shanahan wrote:
> Peter Firmstone wrote:
>> Hi Patricia,
>> I haven't completed the second round of tests yet, these should be 
>> complete by morning.  I don't think it's safe to assume absence of 
>> failure precludes it.
> Indeed. As I noted in the first request for the test, a hit would 
> quickly refute the hypothesis. A lack of hits does not tell us 
> anything at all. The hypothesis, that sequence number sensitive tasks 
> are added in sequence number order, can only be confirmed by analysis.
>> We can see the potential for failure, we just haven't simulated the 
>> conditions for it I suspect.
>> You should be able to run the qa tests yourself with ant qa.run, we 
>> should probably look at how we can run some simulations using the qa 
>> suite.
> It is *should" be able, not can. I'll take another run at trying to 
> get a working test environment.
> If the check for retry messages in the log does not show a significant 
> number, I will work on a modification to RetryTask to force retries. I 
> am confident, based on analysis of some RetryTask subclasses, that at 
> least one of two statements is true:
> 1. Tasks that sequence number conflict with a task that is in the 
> retry process are never added, and the non-trivial runAfter test is a 
> waste of time. This seems unlikely to me.
> 2. During retries, sequence number sensitive conflicting tasks can get 
> out of order.
> Patricia

View raw message