test.compliance status

[squirest]

Ok,

We have issues in test.compliance.

First of all, ModelMBeanTEST.java:85 is a failure 100% of the time. Juha, is that yours? I think it's a NullPointerException in the PersistenceInterceptor constructor (just below a row of FIXMES).

Next, monitor.BasicTEST:187 and timer.BasicTEST:88 are failing intermittently. Adrian, it seems there's a threading issue there.

Other than that we're clean. Time to write some harder compliance tests.

Trev

[adrian.brock]

Trevor,

Yeh, both tests are multi-threaded.
I made the timing parameters quite tight so as not to
slow down the testsuite.
Both my PCs are pretty fast so I wasn't sure what
values to use.
It really depends upon how long it takes the JVM/CPU
to do a context shift between threads.

You could try doubling the values for period and wait.
The timing is less significant for the monitor tests,
the wait could easily be increased without affecting the
test.

I'll try to think of better way of doing it when I do the
proper unit tests. :-)

Regards,
Adrian

[juha]

> First of all, ModelMBeanTEST.java:85 is a failure
> 100% of the time. Juha, is that yours?

yeah, I broke something about a week ago and haven't had the energy to go back and track down what it was yet... :D

will get there B-)

[squirest]

Adrian,

I've been hitting the problem you mention in the comments for monitor.BasicTest - the RI is hanging.

These multithreaded tests should be rewritten so that instead of relying on Thread.sleep()we use a monitor.

I.e. in handleNotification you do something like:

synchronized( receivedNotifications )
{
receivedNotifications.add( notification );
receivedNotifications.notifyAll() ;
}

Then each assertion would be more like:

setAttribute()
synchronized( receivedNotifications )
{
if (receivedNotifications.size() > ) fail ("too many notifications") ;
else if (receivedNotifications.size() == ) receivedNotifications.wait(5000);

if (receivedNotifications.size() != ) fail("timeout waiting for notification") ;
}

That way we can have a more forgiving wait for the notifications without slowing down the tests too much.

Trev

[adrian.brock]

Thanks,

I was going to look at this, once I've migrated the tests
to the Automated testsuite :-)

Regards,
Adrian

[adrian.brock]

Hi Trevor,

Applied your mod to the monitor tests. It works
quite well, of course it runs slower to cater for
slower machines. I'm now allowing 100ms between
monitoring and 200ms for a notification to occur (or
not occur).

I've done a similar mod in the Timer test, but it
raised an interesting issue.

Since the test is now synchronized with the Timer
service, the test now gets to run before the Timer
service has had chance to remove the notification.

Should the timer service remove the notification
from its list before sending the notification?
The specs not clear, it implies it should remove
after the send. Certainly that is what the RI does.

I think it is more deterministic to remove the
registered notification before sending the
TimerNotification, but then the handler can't
query the TimerService for information about the
notification id.

I had to put a Thread.yield() in the test to give the
timer service chance to remove the notification, otherwise the RI hangs when you try to run stop().
It deadlocks.

First time I've ever used Thread.yield() :-)

Regards,
Adrian

[juha]

added temp fix for the persistence NPE, compliance should be clean now

test-compliance-JBossMX:
[java] .........................................
[java] .........................................
[java] .........................................
[java] .........................................
[java] ..............................
[java] Time: 3,044
[java]
[java] OK (194 tests)
[java]

test-compliance:

BUILD SUCCESSFUL

Total time: 10 seconds
Press any key to continue . . .