Patricia, I suggest you to try the GigaSpaces implementation. We solved this issue long time ago. We have a free community edition, so you can download it and use it in production. Take a look also on our exclusive locking option. You might find it useful. Shay
----- Original Message ----- From: Patricia Shanahan <p...@acm.org> To: river-dev@incubator.apache.org <river-dev@incubator.apache.org> Sent: Thu Dec 02 23:27:15 2010 Subject: Progress, and a problem I'm currently hunting an intermittent bug found by the test qa/src/com/sun/jini/test/impl/outrigger/matching/StressTestWithShutdown.td After a failure on Hudson, I modified the .td file to make it fail more often by increasing the number of entries (10,000), readers (1000), and writers (1000). The writers write entries in an OutriggerServerImpl JavaSpace. The readers read, and then take, entries that the writers wrote. Sometimes, a reader fails to find an entry a writer claims to have written, causing a timeout. The outrigger implementation depends on the class FastList which seems to use the infamous Double Checked Locking idiom (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html) The good news is that any memory model related error in FastList, or the related class EntryHolder, would be a plausible cause of the observed symptom. The bad news is that FastList and EntryHolder seem to have been written to be very aggressively parallel, possibly by someone who was only familiar with sequentially consistent memory. :-( Usually, it is easy to fix a problem once it has been located. This may be a bit more difficult, especially because I assume the parallelism is needed for acceptable JavaSpace performance. Patricia
