Seems to me that FIFO handling would be a bit of an illusion at the best of times. What happens if you take an entry within a transaction, then the transaction gets rolled back? The entry gets dropped back into the space, in a different order than the original.
I've always assumed that if you want to process entries in order, you need to pull them all and re-order locally, or put a sequence number as a field, then take() them in the order you want them. By the way, I'm casually assuming the model where you're using the space as a messaging medium rather than storage. Your mileage may vary. Cheers, Greg. On Mon, 2010-12-20 at 16:19, 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 > > -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
