Re: LookupCache, ServiceDiscoveryListener and discard guarantees

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

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