On Sat, 2013-09-14 at 20:15, Geoffrey Arnold wrote: > Hey Greg, thanks the quick response!! > > So if I'm understanding correctly, the idea is a service can join a djinn, > register with a LDS, and then deactivate. Then, when the LDS discovers a > new JLUS, the LDS will callback to the service, thereby activating it. The > service can then register with the newly-discovered JLUS, if it so desires. > Makes sense. >
That seems to be it. Now, I suspect that the use case for activatable services is kind of rare. I think you'd need a case where you had a huge number of services dormant at any one time, in order to justify the added complexity. I'd be curious as to whether anyone has come across such a use case. Cheers, Greg. > > > On Fri, Sep 13, 2013 at 6:54 PM, Greg Trasuk <[email protected]> wrote: > > > > > > > Geoff: > > > > Good to see you in these parts again. > > > > Gotta confess, I've never understood that one myself. At the same > > time, I've never attempted to use activatable services, which is > > probably why I haven't come across this problem. > > > > Having said that, reading through the LDS Spec, it seems that it's > > designed to deal with discovery in the case of activatable services. > > > > <quote from docs/spec/html/lds-spec.html> > > > > The facilities of the lookup discovery service are of particular value > > in a scenario in which a new lookup service is added to a long-lived > > djinn containing multiple inactive services. Without the use of a lookup > > discovery service, the time frame over which the new lookup service is > > fully populated can be both unpredictable and unbounded. > > > > To understand why this time frame can be unpredictable, consider the > > fact that an inactive service has no way of discovering a new lookup > > service. This means that each inactive service in the djinn that wishes > > to discover and join a new lookup service must first activate. Since > > activation of a service occurs when some client attempts to use the > > service, the amount of time that passes between the arrival of the new > > lookup service and the activation of the service can vary greatly over > > the range of services in the djinn. Thus, the time frame over which the > > lookup service becomes fully populated cannot be predicted because it > > could take arbitrarily long before all of the services activate and then > > discover and join the new lookup service. > > > > In addition to being unpredictable, the time it takes for the lookup > > service to fully populate can also be unbounded. This is because there > > is no guarantee that the lookup service will send multicast > > announcements between the time the service activates and the time it > > deactivates. If the timing is right, it is possible that one or more of > > the services in the djinn may never discover and join the new lookup > > service. Thus, without the use of the lookup discovery service, the new > > lookup service may never fully populate. > > </quote> > > > > Greg. > > > > On Fri, 2013-09-13 at 18:04, Geoffrey Arnold wrote: > > > Hello again, old friends :) > > > > > > I was recently singing the praises of Jini which inspired a few of our > > devs > > > to go check it out. One particularly precocious engineer came back with > > a > > > question about the LookupDiscoveryService, and after considering a number > > > of common Jini-related tasks I still couldn't come up with a valid use > > > case. Any thoughts would be greatly appreciated. > > > > > > Thanks, > > > Geoff. > > > >
