[FRG-286] intermittent failure in FarragoObjectCacheTest.testMultipleThreadsExclusive

[dynamobi-build]

[reporter="jhyde", created="Thu, 19 Jul 2007 14:29:46 -0500 (GMT-05:00)"] FarragoObjectCacheTest.testMultipleThreadsExclusive fails intermittently, as follows:

Failure in FarragoObjectCacheTest. I think it's intermittent. Investigating.

Testsuite: net.sf.farrago.test.FarragoObjectCacheTest
Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 6.069 sec

Testcase: testOneThreadOverlappingExclusive took 0.002 sec
Testcase: testOneThreadSequential took 0 sec
Testcase: testOneThreadSequentialStale took 0.001 sec
Testcase: testOneThreadSequentialNonReusable took 0 sec
Testcase: testOneThreadShared took 0 sec
Testcase: testOneThreadVictimization took 0.028 sec
Testcase: testOneThreadFailedInitialization took 0.001 sec
Testcase: testMultipleThreadsExclusive took 3.007 sec
        FAILED
expected:<0> but was:<4>
junit.framework.AssertionFailedError: expected:<0> but was:<4>
        at
net.sf.farrago.test.FarragoObjectCacheTest.tearDown(FarragoObjectCacheTest.j
ava:96)

Testcase: testMultipleThreadsShared took 3.024 sec

I got 3 failures in 54 runs on my on my dual-code AMD; reproduced on //open/dt/dev and //open/dev.

I have disabled testMultipleThreadsExclusive.

[dynamobi-build]

[author="jvs", created="Thu, 19 Jul 2007 14:32:39 -0500 (GMT-05:00)"] Yes, sorry, Steve H ran into it also, and it's been showing up on the very slow cruise.eigenbase.org also.

[dynamobi-build]

[author="jvs", created="Sat, 21 Jul 2007 04:20:50 -0500 (GMT-05:00)"] Found the problem. It's a real bug in FarragoObjectCache (not a problem with the test) and can cause testMultipleThreadsShared to fail also.

Running through with fix on zeugma (where the bug repros easily) for the rest of the night to make sure.

[dynamobi-build]

[author="jvs", created="Sun, 22 Jul 2007 11:28:03 -0500 (GMT-05:00)"] Fixed in eigenchange 9636.

The workaround I had put in for MultiMap remove() limitations had a subtle bug associated with it: I was comparing against the size() to detect which list variant was being iterated, but the size changes after deletions!

It would be nice to fix up MultiMap (so that the workaround can be removed) and add unit tests to it, but leaving that for another day.

[dynamobi-build]

[author="jvs", created="Sun, 22 Jul 2007 11:31:42 -0500 (GMT-05:00)"] The impact was that objects could slip out of the cache improperly in very rare circumstances; the cache would no longer hold a reference, but it would still track the bytes as in use, and the objects would never get their closeAllocation() method called.