Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: error (athena.apache.org: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: River-examples project - followup
From: Greg Trasuk <trasukg@stratuscom.com>
In-Reply-To: <BFF3D875-25F4-48D8-94F8-753250052847@gmail.com>
Date: Mon, 6 Apr 2015 15:30:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <417F3B49-58E0-4539-A969-3F69A9A54194@stratuscom.com>
References: <BFF3D875-25F4-48D8-94F8-753250052847@gmail.com>
To: dev@river.apache.org


Hi Dan:

Thanks for the great feedback. =20

I=92m pretty sure you already know this, Dan, since you=92re a long-time =
Jini user, but let me explain for the newer folks and the archives.  =
This is a case where what you=92re 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=92s JoinManager (that isn=92t quite the whole story, but it=92ll =
do for now).  When you kill the service unexpectedly with ctrl-c, the =
service doesn=92t de-register itself, however the lease eventually runs =
out (now that it=92s not being renewed by the service) and then the =
registration expires, allowing Reggie to reclaim its resources and =
notify any registrar listeners.=20

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=92s 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 =93worked=94, in that you can =
show info and browse the service, but of course, you=92re really just =
looking at the information that=92s in the registry - the registrar and =
service browser don=92t actually contact the service.  Reggie has no =
knowledge of the =93liveness=94 of the service, and doesn=92t attempt to =
do any =93health check=94. =20

In fact, it=92s a common misconception that if the service renews the =
lease, it must be =93live=94.  This turns out to be false for many =
reasons.  (1) The service could have delegated its lease renewals to a =
different service.  (2) There=92s 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 =93resetting the watchdog in a =
timer-triggered interrupt service routine=94 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 =
=93works=94 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=92t =
renewed, Reggie drops the registration.  So there=92s little risk of =
=93stuck registrations=94.  And since the lease can be renewed, there=92s =
no need for any kind of extended default timeout.

So, I think I=92ll 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 <danrollo@gmail.com> wrote:

> Hi Greg,
>=20
> I finally took some time to try this out. It really looks great to me!
>=20
> 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 =93worked=94 (I =
could =93show info=94 and =93browse service=94 on all of them). =
Eventually, the duplicate registrations =93cleaned up=94 and I was left =
with just one. I=92m not sure how best to avoid confusion about this =
situation. Would more doc about =93why=94/=93how=94 that works just =
complicate things? Is there any sort of =93force lease check=94 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 =
=93problem=94, but thought I=92d ask=85
>=20
> Thanks!
> Dan
>=20
> <revier-examples-RepeatedService.png>