Oh yeah, I remember this one! I reckon we could avoid that table with a simple exponential back-off algorithm and then have a means to cap/set a maximum period of time programmatically or via config or both.
On 2 January 2013 15:49, Dennis Reedy <[email protected]> wrote: > > 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. >
