Re: [ cayenne-Bugs-646399 ] Spurious failure of RequestQueueTst

From: Craig Miskell (cmiskel..lbatross.co.nz)
Date: Mon Dec 16 2002 - 16:40:49 EST

  • Next message: Andrus Adamchik: "Re: Spurious failure of RequestQueueTst"

    On Tue, 2002-12-17 at 10:25, Holger Hoffstätte wrote:
    >
    > Guys,
    >
    > I've spent some more time with the infamous RequestQueue failure and can
    > confirm that Craig's comment below really describes the cause of the
    > spurious failures:
    >
    > > I think I've figured out what's wrong, but not how to fix
    > > it. If you turn on debug in log4j, it turns out that
    > > "thread-4" is getting started before "thread-3", or rather,
    > > the particulars of timing means that thread-4 gets a go at
    > > executing before thread-3. For a failed test, the following
    > > (..)
    > > So, I *think* I know the fix, but not how to do it. After
    > > starting thread-3, the test needs to wait for that thread to
    > > be properly enqueued (loop waiting for
    > > RequestQueue.getSize() to return >0 maybe?).
    >
    > Yes, this will stop the test from failing and is a good quick fix for both
    > testQueueFull() and testWaitTimedOut(). I added the following to all tests
    > after the first thread start():
    >
    > while (testCase1.getQueue().getSize() == 0) {
    > Thread.yield(); // same as sleep(reallySmallAmount)
    > }
    >
    > and ran everything several hundred thousand times now without a single
    > failure. In order to fix the test this might really be the quickest and
    > safest solution. Unfortunately I don't think it solves the root of the
    > problem. :(
    >
    > IMHO everything should work without this manual caretaking - what if I
    > really want to start() a couple of threads in quick succession and the
    > queue is full?
    I think that the fix truly fixes the unit test, in as much that
    testQueueFull needs to be sure that the queue is full first before it
    can test to see if a further thread is 'correctly' rejected. The
    "manual" caretaking is part of ensuring the test environment is correct
    (and I think the same logic applies for testWaitTimedOut, but this stuff
    gives me a headache real quick :-))

    In the situation you describe, all threads should return QUEUE_FULL
    immediately. If you start multiple threads when the queue is not full,
    and along the way the queue gets full, then which threads are rejected
    is arbitrary (like all thread programming :-( ).

    I'm afraid I didn't really understand the rest of your e-mail (totally
    my end... I really need a holiday... 1 1/2 days to go :-)). But I'm
    thinking maybe what I said above helps somehow. You never know :-)

    >
    > So, for a quick fix the manual waiting is IMHO OK and should be applied
    > ASAP since the occasionally failing test really does not build confidence.
    Ooops, understood this bit... agreed totally.

    Craig



    This archive was generated by hypermail 2.0.0 : Mon Dec 16 2002 - 16:38:47 EST