On Tue, 2012-07-10 at 10:14, Itai Frenkel wrote: > >> Are you sure about that? > Looking at RegistrarImpl when ThrowableConstants.retryable(e) returns > BAD_OBJECT, it rethrows only if (e instanceof Error), otherwise it cancels > the lease. Since ConnectException is not an Error the lease would be canceled. > Why is the Error check being performed ? > ThrowableConstants.retryable(e) only returns BAD_OBJECT if it receives a definite response from the remote endpoint. For a comm failure, it should return INDEFINITE. Having said that, the logic seems to favour declaring an exception "Definite" where it might be arguable. For instance, it will declare BAD_OBJECT in the case of a "No route to host" exception, which arguably could be temporary, for instance if a router goes offline.
> >> Personally, I'd use an internal timer on the client side that says "if I > >> don't receive any events for a given time, I'll cancel the current lease > >> and re-register". > That requires the Registrar to periodically send probe notifications. The > number of real world notifications could fluctuate from zero to high load and > cannot be trusted without probe notifications. > Might be an interesting improvement if a client could request a heartbeat or supervisory message from the registrar. But my point above was that if the events are not coming fast enough to satisfy a reasonable "liveness" timeout, then it's probably not a big problem if the client simply cancels the lease and re-registers. So you could effectively implement your own heartbeat. Alternately (subject to exploring the loading and the number of clients) you could create a service that does nothing but registers, then updates its service attributes periodically, which would have the effect of generating registrar messages. Starting to get a little complicated and indirect, though. In the end, however, it seems like your trying to have the client find out that it's not receiving registrar notifications. I can't think of any better evidence than "you're not receiving registrar notifications". Cheers, Greg. > Thanks, > Itai > > -----Original Message----- > From: Greg Trasuk [mailto:[email protected]] > Sent: Tuesday, July 10, 2012 4:36 PM > To: [email protected] > Subject: Re: Question about LeaseRenewalManager and renewDuration > > > On Tue, 2012-07-10 at 06:41, Itai Frenkel wrote: > <snip...> > > Background Information: > > The motivation for this is the way the Registrar handles event > > notifications. > > When the Registrar fails to send a notification to a listener due to a > > temporary network glitch, it assumes the listener is no longer available > > and cancels the event lease. > > Are you sure about that? Looking through com.sun.jini.reggie.RegistrarImpl, > it appears that when an exception occurs during event notification, the code > tries to categorize the exception as either "definite" (no such event, no > such object, etc) or "indefinite" (communications failure). Then it only > cancels the lease on a definite exception. > > In other words, the lease is maintained in the case of a temporary network > failure. After all, that's the whole point of the lease: it represents an > agreement between the client and service that resources are going to be > maintained for a definite time period. > > Personally, I'd use an internal timer on the client side that says "if I > don't receive any events for a given time, I'll cancel the current lease and > re-register". If the events are that quiet, then clearly the registrar is > not that heavily loaded, so the overhead of cancelling the lease and creating > a new registration should not be too bad. You'd want to test it under > simulated load, of course. > > Cheers, > > Greg. > -- > Greg Trasuk, President > StratusCom Manufacturing Systems Inc. - We use information technology to > solve business problems on your plant floor. > http://stratuscom.com > > >
