Re: Lookup Service Discovery

Hi Mark

Thanks for the response.

Since I wrote the post, I have found a solution that works for now,
but it will be interesting to try out your suggestions when I get
time. Some notes

1) AFAIR, the service id was new on each restart
2) I tried with various timeouts between restarts, but it was easy to
produce the failure to find the new (or restarted) LUS without a long
delay
3) I did verify that the LookupCache is getting events; I attached a
"logging" listener to the cache, and verified that as I restarted the
service, the cache received add/discard events. It did not seem to
pick up events from new LUS instances, however.
4) I believe I also attached a DiscoveryListener to record when LUS
instances were found; IIRC, the restarted instances were *not* found

We are using an SDM with a LookupDiscoveryManager configured (only)
with a single group name for discovery. My reading of the
documentation for SDM and LDM left me uncertain about whether either
the SDM or the LDM would continuously perform discovery for lookup
services after the first, successful multicast search had returned.
The documentation for SDM refers to "the managed set of lookup
services" (see docs for createLookupCache()), and it wasn't clear to
me when the managed set is created, and whether it is
maintained--whether the set is fixed or not--from the documentation.
Running with a higher logging level may help sort that out.

In the end, I backed off to a conservative approach. If we don't have
a service reference, or we have discarded our references after
receiving RemoteExceptions, we create a Future to schedule a new
search (only one future at any time for a given service type). The
search begins by terminating the lookup cache, discarding any
registrars currently in the SDM (via LDM.getRegistrars(), then
discard() on each), calling LDM.setGroups(NO_GROUPS), then
LDM.setGroups(group). We then wait for incoming service matches, with
a timeout. If no services are received by the timeout, the future
completes and a new one will be scheduled on the next call to get a
service reference.

In one way of looking at it, that's a little expensive, but our goal
is to avoid restarting our clients (which impacts our end users in the
worst way) but allow us to restart our services when necessary. Since
service restart should be an rare action once the services are stable,
we can absorb the extra cost of discovery for lookup services. The
clients, of course, need to be coded to handle the case of "no service
available".

It's also possible that by playing with the configuration for the
LookupDiscovery the problem will be solved. I haven't tried modifying
those, and the problem may lie there.

I will try to squirrel away some time to get a test case running
again, so I can send some logs to the list. At my level of Jini
experience, I find it to be an interesting problem :). The bulk of the
test case was done via the starter kit, the only custom part was the
lookup client, for which I can't directly release the code; however, I
should be able to mock up something similar that shows the effect.

Having not found any specific references to these sorts of problems in
the mailing lists, and given my level of experience with Jini, I'm
inclined to believe this is a case of operator error.


Regards
Patrick

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