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