Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: datastructure classes
From: Greg Trasuk <trasukg@stratuscom.com>
To: river-dev@incubator.apache.org
In-Reply-To: <AANLkTin+JVnV-7uG2uvwxP5Giub+amfiNtGwzHxOHytL@mail.gmail.com>
References: <4CF89BD3.3030103@acm.org> <4CF909A0.5070409@wonderly.org>
	 <4D056E41.7020102@acm.org> <4D057B73.3090905@zeus.net.au>
	 <4D05BA22.4000002@acm.org> <4D06672A.10203@wonderly.org>
	 <4D066FA2.8050207@wonderly.org> <4D069D21.5070908@zeus.net.au>
	 <4D06BA8D.4040602@simulexinc.com> <4D06C523.5000006@acm.org>
	 <5E44AB11-EC78-476E-8A6D-C9AEBEFCA3D2@topiatechnology.com>
	 <4D079D60.4070607@wonderly.org> <4D07E442.5040908@acm.org>
	 <39AED645-40CC-4314-9956-25BE1325B2F5@topiatechnology.com>
	 <4D07E9D4.2080106@acm.org>
	 <B9558304-8B77-4CFB-B23B-73A29D89B65F@topiatechnology.com>
	 <4D0856B2.1070107@acm.org>
	 <DD8D109E-0158-438A-ADB0-F8180C8B01A8@topiatechnology.com>
	 <4D0A1A61.2020805@acm.org> <4D0A1D90.2000900@qcg.nl>
	 <4D0B8903.8090704@wonderly.org> <4D0BFA6D.80201@acm.org>
	 <AANLkTimzaLEMmb6iRPPWAsVgRyc8bvyfrGTHzt9NnPUw@mail.gmail.com>
	 <4D0FBCCD.8080506@acm.org> <4D0FBF6A.1070504@wonderly.org>
	 <AANLkTin+JVnV-7uG2uvwxP5Giub+amfiNtGwzHxOHytL@mail.gmail.com>
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <1292889664.4894.56.camel@cameron>
Mime-Version: 1.0
Date: Mon, 20 Dec 2010 19:01:04 -0500
Content-Transfer-Encoding: 7bit


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