river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: datastructure classes
Date Tue, 21 Dec 2010 00:01:04 GMT

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 <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
> >
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


Mime
View raw message