river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: datastructure classes
Date Mon, 20 Dec 2010 21:19:15 GMT
If that's what is required, you'd best change the spec to reflect this
default. Failing to do this leaves developers open to nasty surprises like:

(1) Develop code on javaspace that supports FIFO by default.
(2) Pronounce code safe and debugged.
(3) Deploy code onto some other javaspace (e.g. a commerically supported one
to keep management happy).
(4) Be assaulted and confused by the sudden appearance of problems with code
that ran just fine before for no apparent reason.

As Tom hints below, this problem is already with us so sorting out specs and
such cannot be a bad thing.

"But, without some sort of implicit ordering, there is a chance of
starvation or at best prolonged staleness of entries which can turn people
off of JavaSpaces as a solution for all out performant network applications,
and that is exactly what we don't want."

I'd note that for anything other than the least demanding (concurrency wise)
"performant network applications" FIFO is a performance killer that might
well put developers off anyways. As with so many things Javaspaces there are
two sides to every tradeoff and neither is perfect for all cases.

On 20 December 2010 20:41, Gregg Wonderly <gregg@wonderly.org> wrote:

> On 12/20/2010 2:30 PM, Patricia Shanahan wrote:
>
>> Tom Hobbs wrote:
>>
>>> I know of at least one company which uses Outrigger specifically
>>> because of it's fortuitous FIFO behaviour. I'm trying to encourage
>>> them to move from the Jini 2.1 code to the River release and losing
>>> the FIFO-ness might be an issue for them.
>>>
>>> And yes I know, the spec doesn't specify FIFO, like I said, they
>>> needed a FIFO space, and Outrigger "just happened" to behave like
>>> that.
>>>
>>
>> That confirms my suspicion that FIFO-ness is a useful property. I note
>> that
>> Gigaspaces has optional support for FIFO.
>>
>> My quick changes to try to fix the current bug will preserve it. If the
>> long
>> term design loses it for flat-out performance, we should make it available
>> on a
>> configuration basis.
>>
>
> In any case, I think it is important to think strongly about supporting
> FIFO as the default behavior.  This helps people see and appreciate
> "progress" of
> Entry values within their system.  If better, predictable, performance can
> be had from non-FIFO ordering, that would be great.  But, without some sort
> of implicit ordering, there is a chance of starvation or at best prolonged
> staleness of entries which can turn people off of JavaSpaces as a solution
> for all out performant network applications, and that is exactly what we
> don't want.
>
> Gregg
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message