I took a quick look at GigaSpaces, and I don't think it meets the
minimum requirements for a River outrigger replacement.
A satisfactory replacement must have Apache-like binary licensing for a
version that is no more restricted than outrigger, so that any River
user who depends on outrigger now, or might depend on it in the future,
can use the replacement just as freely. Open source would also be very
desirable, to enable future River-specific tuning and enhancements.
As far as I can tell, GigaSpaces is a closed source commercial product
with a community edition that is free but restricted to a single node.
According to http://www.gigaspaces.com/LatestProductVersion, the
community edition "... is useful for testing, development and
small-scale deployments.".
Thanks for the suggestion, but I don't think you understood the
requirements.
Patricia
On 12/4/2010 11:57 AM, Shay Hassidim wrote:
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<[email protected]>
To: [email protected]<[email protected]>
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
