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
