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 <gr...@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 mmcgr...@topiatechnology.com
