Re: JavaSpace.notify() "not reliable"

Gregg Wonderly wrote:
>
>
> Dan Creswell wrote:
>> Timur Mehrvarz wrote:
>>> On 11.05.2007, at 05:19, Gregg Wonderly wrote:
>>>> Are you using the returned value from notify to get the associated
>>>> Lease,
>>>
>>> Yes.
>>>
>>>> and then passing that off to a LeaseRenewalManager, or otherwise
>>>> renewing it?
>>>
>>> I do not renew my Lease. I usually need to apply a different search
>>> template, everytime I call notify(). So I cancel() the lease, take() the
>>> object from space, start a new notify() and do a wait(). I can see how
>>> the worker thread is always calling the notify(), before the master
>>
>> How have you confirmed and/or guarenteed that the master writes the
>> object into the space after the notify()?
>
> 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.

> 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!

> 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".

Dan.

===========================================================================
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