On Jan 2, 2013, at 916AM, Dan Creswell wrote:
> Hey Dennis,
>
> Thanks for this...
>
>>> The thing about getting these locators from the registrar itself is
>>> that you have to have located the registrar in some other way
>>> previously (e.g. via multicast).
>>>
>>> Question then would be, who uses unicast lookup locators and why?
>>
>> I've used locators most always when deploying into production because
>> multicast is typically turned off. We've done other crafty things like
>> writing a tunneling service (Lincoln) that forwards Jini Lookup Service
>> Announcement requests and Jini Request announcements from one network to
>> another, and also providing a different approach by using a gateway service
>> on a well pre-defined addr:port that dispenses LookupLocators based on the
>> lookup discovery groups being sought after.
>>
>> I've found locators to be key. I dont use them for firewalls, just for
>> deployments where multicast is turned off.
>>
>
> Okay, and how would you obtain those LookupLocators right now? I guess you'd
> be doing that by knowing which boxes you had Registrars on and
> what ports they were configured to after which you'd manually concoct the
> URL's?
Once you know the locator details, we put the locator setup in service
configuration files, and/or default to a system property (same approach to
group configuration). If we were using the gateway approach, then we would
connect to the gateway and get a locator back based on the requested group.
>
> Obviously, I'm keen to support this sort of thing if it's common and
> we're not doing a good job right now.
Tangential to this discussion is an issue that was found with re-discovery of
lookup services that may have failed, or might have been disconnected for one
reason or the other when relying on unicast discovery (I think this has been
brought up here in the past). The default unicast retry protocol provides a
graduating approach, increasing the amount of time to wait before subsequent
discovery attempts are made - upon each invocation, eventually reaching a
maximum time interval over which discovery is re-tried. The approach has been
implemented in this way so the network is not flooded with unicast discovery
requests. The downside here is the perceived responsiveness of the system,
since services may come and go during the retry window. Take a look at the
LookupLocatorDiscovery.calcNextTryTime() method. The default time to wait
between unicast retry attempts are:
long[] sleepTime = {5 * 1000, 10 * 1000, 20 * 1000,
30 * 1000, 60 * 1000,
2 * 60 * 1000, 4 * 60 * 1000,
8 * 60 * 1000, 15 * 60 * 1000};
You'll max out at 15 minutes between retries. Thats a big window.
