river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MICHAEL MCGRADY <mmcgr...@topiatechnology.com>
Subject Re: datastructure classes
Date Tue, 21 Dec 2010 00:39:42 GMT
What is the spec that is being potentially changed?  Outrigger can promise FIFO but this does
not mean, I assume, that other implementations of JavaSpaces have to deliver FIFO as well.
 Pulling an implementation into the specs for JavaSpaces would, I think, be counter-productive.

MG

On Dec 20, 2010, at 1:19 PM, Dan Creswell wrote:

> 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
>> 

Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com




Mime
View raw message