Re: LookupCache, ServiceDiscoveryListener and discard guarantees

Mark Brouwer wrote:
> Hello Rick,
>
> Rick Moynihan wrote:
>
>> My question given this setup is:
>>
>> Does the LookupCache guarantee that the serviceRemoved() method call in
>> honour of the call to discard() will occur prior to a call to
>> serviceAdded() due to the rediscovery of the lost service?
>>
>> The fear is the admittedly unlikely event of the client issuing the
>> discard() just as the service is coming back online, and that
>> serviceAdded() is called prior to the already initiated (but not yet
>> run) serviceRemoved().
>>
>> If this were to occur the Jini layers would know about the service but
>> my application wouldn't as it would have removed the newly added
>> service.  Are any assurances made by LookupCache that calls to discard()
>> will result in serviceRemoved() method invocations prior to any calls to
>> serviceAdded()/serviceChanged() involving the discarded service?
>>
>> I've done a fair amount of searching and have read through the Jini
>> Service Discovery Utilities Specification[1], but can't find any mention
>> of this.
>>
>> Is this something worth worrying about?  And do I need to ensure that
>> the remove is called before the add in the case of a discard?
>
> Very good question, I had to go into the implementation as indeed the
> specification was not clear enough about that. The specification for
> ServiceDiscoveryListener (at the end of
> http://java.sun.com/products/jini/2.1/doc/specs/html/servicediscutil-spec.html#1004669)
>
> makes some concurrency guarantees, i.e. "for any given listener object
> that implements this interface or any sub-interface, no two methods
> defined by the interface or sub-interface will be invoked at the same
> time by the same cache. This applies to different invocations of the
> same or different methods, on the same or different listeners registered
> with a single cache.".
>
> But when checking the ServiceDiscoveryManager for your answer I think
> (it is rather complicated code) the current implementation doesn't seem
> to implement that guarantee. There is some sequential processing
> enforcements but that is related to the ServiceID from which the events
> originate but given the various places from where these invocations can
> take place but to me it doesn't look like there is proper
> synchronization as the ServiceDiscoveryListener seems to require. No
> doubt the authors will chip in to elaborate or to correct me.
>
> Whether the above really matters I can't say for sure given the fact
> that events originating from a particular lookup service seems to be
> properly synchronized (not sure about all cases though).
>
> Back to your specific question. It is good to understand that when you
> discard your service that it isn't really removed from the LookupCache,
> it is actually being marked as being 'discarded', if the service was
> really crashed and it reregistered with a lookup service under the same
> ServiceID (maybe with different attributes) than that is recorded but it
> stays in the 'discarded' state, i.e. you won't get a service added
> notification. Only after a certain amount of time has elapsed it is
> verified whether the service is really gone or that it should be
> considered 'rediscovered' [1], in the latter case you will get a service
> added notification.
>
> So based on the above you can conclude that as long as the processing of
> your service removed event is less than the 'rediscover' period (10
> minutes) you won't get into any problems.
>
> The ServiceDiscoveryManager (SDM) is a rather
> complicated utility that does a very good job on providing a view of all
> the the services out there, but given its complexity I don't dare to say
> it is 100% OK ;-)
>
> Hope this helps.
>
> [1] a quick look seems to indicate the service added notification could
> overlap with a TRANSITION_MATCH_MATCH event from a lookup service for a
> given ServiceDiscoveryListener. Also overlap seems to be possible when
> you add a listener to an existing cache through
> LookupCache.addListener() and becomes visible to the asynchronous tasks
> in LookupCacheImpl while it is being notified of the current state of
> the LookupCache. This latter case worries me as I have quite some code
> that through addListener expects to build a 'proper' view of the
> services available, a broken ordering (a remove before an add) here
> would be annoying but likely an exception against a service that ends up
> in your view will make you discard it anyway and correct your view.
> --
> Mark

Hi Mark, thanks for your prompt response.  I was already aware of the
semantics of discard() and the LookupCache regarding it's use of a
separate 'limbo' storage area to protect against things like selective
net-splits between the client and service and not the service and
lookup-service.

What I didn't realise until reading your response was that the actual
rediscovery of the service is delayed by the discardWait.  This, as you
say, should solve the problem unless the processing of removal is longer
than the discardWait.  With a 10 minute discardWait being many orders of
magnitude greater than the necessary processing time, this seems so
incredibly unlikely to occur in practice that it's really not worth me
worrying about.

Before posting I'd also taken a peek at the source for LookupCacheImpl
and ServiceDiscoveryManager.  And you're not kidding about how many
details it takes of!  We recently reimplemented/simplified some old code
that did not previously make use of these classes.  And I'm glad we did,
though we did also need to build a layer above them to cache
LookupCaches across services running within the same VM.

Thanks again for your response,

--
Rick Moynihan
Software Engineer
Calico Jack LTD
http://www.calicojack.co.uk/

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]