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:41:25 GMT
I also agree.

MG

On Dec 20, 2010, at 2:22 PM, Gregg Wonderly wrote:

> On 12/20/2010 3: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.
> 
> I completely agree.  There are many avenues of success and failure each with both detracting
and meritorious viewpoints.
> 
> Gregg
> 
>> 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