Hi Dan:
Thanks for the great feedback.
I’m pretty sure you already know this, Dan, since you’re a
long-time Jini user, but let me explain for the newer folks and
the archives. This is a case where what you’re seeing is the
expected behaviour. When the service registers itself with
Reggie, it takes out a lease on the registration. That lease is
usually renewed periodically by the service’s JoinManager (that
isn’t quite the whole story, but it’ll do for now). When you
kill the service unexpectedly with ctrl-c, the service doesn’t
de-register itself, however the lease eventually runs out (now
that it’s not being renewed by the service) and then the
registration expires, allowing Reggie to reclaim its resources
and notify any registrar listeners.
It would be possible to register a vm shutdown hook to
de-register the service before the vm exits, but in this case I
think it’s actually better to leave it out, since it demonstrates
nicely that a dead service (or at least a dead JoinManager)
eventually gets dropped from the registrar.
You said the duplicate service instances “worked”, in that you
can show info and browse the service, but of course, you’re
really just looking at the information that’s in the registry -
the registrar and service browser don’t actually contact the
service. Reggie has no knowledge of the “liveness” of the
service, and doesn’t attempt to do any “health check”.
In fact, it’s a common misconception that if the service renews
the lease, it must be “live”. This turns out to be false for
many reasons. (1) The service could have delegated its lease
renewals to a different service. (2) There’s no guarantee that
failure of the actual service thread would also cause failure of
the lease renewal thread, even if they are in the same process
(embedded programmers might recognize this as being similar to
the “resetting the watchdog in a timer-triggered interrupt
service routine” problem). (3) Even if there were a health check
task, the service could fail in the instant just after the health
check. The most a health check, monitor or heartbeat can do is
place a limit on how long it takes to find out a service has
failed. The only way to say with certainty that a service
“works” is to attempt to use it.
The lease is purely for the convenience of the registrar (or
generically, the service granting the lease). If ever the lease
is not renewed, the landlord can go ahead and reclaim whatever
resources were dedicated to the lease. In the case of Reggie, if
the lease isn’t renewed, Reggie drops the registration. So
there’s little risk of “stuck registrations”. And since the
lease can be renewed, there’s no need for any kind of extended
default timeout.
So, I think I’ll put most of the above explanation into the
tutorial, unless anyone has other thoughts.
Cheers,
Greg Trasuk
On Apr 6, 2015, at 1:42 PM, Dan Rollo <danro...@gmail.com>
wrote:
Hi Greg,
I finally took some time to try this out. It really looks great
to me!
I noticed one minor thing that I thought might confuse users:
While going through tutorial steps, I decided to stop (via
cntrl+c) are restart the hello-service a couple times. This
resulted in the service being shown multiple times in the
service browser (screenshot attached). It appeared all the
duplicate instances in the browser “worked” (I could “show
info” and “browse service” on all of them). Eventually, the
duplicate registrations “cleaned up” and I was left with just
one. I’m not sure how best to avoid confusion about this
situation. Would more doc about “why”/“how” that works just
complicate things? Is there any sort of “force lease check” to
do in the browser that could clear up the duplicates sooner?
(And if so, would that be worth noting in the tutorial?). So
basically, not sure this is a “problem”, but thought I’d ask…
Thanks! Dan
<revier-examples-RepeatedService.png>
