Re: JavaSpace.notify() "not reliable"

Dan Creswell wrote:
> Gregg Wonderly wrote:
>> As a general rule of listener use, anytime you add a listener for some
>> kind of notify, you need to query with the same template that the
>> listener has to make sure that there was no item added between the last
>> notify/query and the next notify registration.  Odd things can really
>> happen in distributed systems.
>
> True although in such scenarios one would see the exact same issues in a
> multi-threaded application.  Fundamentally, these issues are caused by
> the interactions of two uncoordinated entities be they separate
> processes or threads.

Right, I didn't mean to indicate otherwise.  The issue is just about how your
software works in the general case of multi threading, whether those threads are
on the same, or separate JVMs.

I try to err on the side of conservative choices.  Software bugs happen.  So, I
tend to always believe that there will be a bug that will keep an atomic view of
something from actually existing.

On the LUS it might be that a service registration could be in progress at the
same time that my listener is being registered.  A simple bug could keep my
listener from being notified of the new service registration.  So, for any
listener interface that includes a query mechanism, I've just taken to always
registering the listener first, and then querying for the current state.  That
way, I've accounted for the behavior that I'd least like to worry about.
Concurrency race conditions will suck the life out of you trying to debug them.

>> With service lookup and the DiscoveryListener, a serviceDiscovered()
>> call, should always request notification first, and then query with the
>> ServiceTemplate.  You may thus see the service "twice", but if you do
>> not do this, a service can be added in the "gap" if you query first and
>> request notify second.
>
> That's one motivation for most to go use ServiceDiscoveryManager or
> LookupCache of course!

Except for notify not working across firewalls, etc.  I've just written off the
conveniences of listeners.  They won't work in all situations without a polling
based implementation (as Mark has done in Seven/"The JSC").  The only working
mode is to register the listener (so that you can get immediate notifications on
local networks where latency will be expected to be minimal), then make the
query to see if there are any there (which covers both the data race in the
server and the non-working call back on listeners case).  Finally, using a
background timer based operation to rerun the query periodically.  I've actually
pushed this into a recovery strategy for failed notify() registrations as well.

>> With Javaspaces, you should typically request notification, and then do
>> a read to see if there is an entry that matches the same template, and
>> then take that entry to process it if so.
>
> Again it's going to depend on your exact scenario.  Small confession:
>
> I often prefer to create designs of such a nature that it isn't critical
> to have implemented the above behaviour.  This is because the above is
> really trying to implement explicitly deterministic behaviour as one
> might with a threaded program.  Once you layer on distributed as well I
> find it's often better to give up on that style of approach and adopt
> something more "loose".

Yes, at some point a better/different solution will float to the top of all this
hacking around system short commings.  After JavaOne this year, it's really
become so apparent how bad of a job we, as the Jini Community, are doing at
making it clear what the best practices are, in one place where these things can
be found.

Gregg Wonderly

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html