6 Replies Latest reply on Feb 3, 2002 6:40 PM by Juha Lindfors

    test.compliance status

    Trevor Squires Novice

      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

        • 1. Re: test.compliance status
          Adrian Brock Master

          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

          • 2. Re: test.compliance status
            Juha Lindfors Master

            > 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-)


            • 3. Re: test.compliance status
              Trevor Squires Novice

              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

              • 4. Re: test.compliance status
                Adrian Brock Master

                Thanks,

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

                Regards,
                Adrian

                • 5. Re: test.compliance status
                  Adrian Brock Master

                  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

                  • 6. Re: test.compliance status
                    Juha Lindfors Master

                    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 . . .