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
