river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Ramsdale <jeff.ramsd...@gmail.com>
Subject Re: Progress, and a problem
Date Sun, 05 Dec 2010 01:51:38 GMT
Shay, as Patricia has clearly stated in the past she's doing this as a
hobby, not looking for a production system. I'd rather see you get
involved in the community than try to draw people away. Free is great
(as is non-free--I have nothing against commerce), but Apache River is
open source. How will you contribute?


On Sat, Dec 4, 2010 at 11:57 AM, Shay Hassidim <shay@gigaspaces.com> wrote:
> Patricia,
> I suggest you to try the GigaSpaces implementation.  We solved this issue long time
> 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 <pats@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

View raw message