Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=939mB+=FL=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.122 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Question about LeaseRenewalManager and renewDuration
From: Gregg Wonderly <gregg@wonderly.org>
In-Reply-To: <1341935376.2131.107.camel@cameron>
Date: Tue, 10 Jul 2012 13:44:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF5A8936-ECD1-4EA6-8318-C728A24D1975@wonderly.org>
References: 
 <3D9D7375DA3CC046A80F455DE3379AFE055EE2@DBXPRD0410MB372.eurprd04.prod.outlook.com>
 <1341927383.2131.38.camel@cameron>
 <3D9D7375DA3CC046A80F455DE3379AFE056114@DBXPRD0410MB372.eurprd04.prod.outlook.com>
 <1341935376.2131.107.camel@cameron>
To: dev@river.apache.org
Sender: Gregg Wonderly <gregg@wonderly.org>

Recall, that under the covers there is also all the OS network stack =
behaviors.  What is the TCP SYN timeout, for example; i.e. how long will =
a TCP connect request, which will eventually fail, take before failing?

I think it's important to understand that unless you are on either end =
of a TCP connection, with timeout and keep alive settings for that =
connection, turned down to short intervals, that you're going to be =
mystified at the longer than expected timing of most failure detections.

Subclassing the appropriate endpoint class, and adjusting it's behavior =
and using that on your registrar may be part of what you need to do, to =
see quick notifications.

Gregg Wonderly

On Jul 10, 2012, at 10:49 AM, Greg Trasuk wrote:

>=20
> On Tue, 2012-07-10 at 10:14, Itai Frenkel wrote:
>>>> Are you sure about that? =20
>> 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 ?
>>=20
> 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.
>=20
>>>> 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". =20
>> 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.
>>=20
> 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.
>=20
> 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.
>=20
> 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".
>=20
> Cheers,
>=20
> Greg.
>=20
>> Thanks,
>> Itai
>>=20
>> -----Original Message-----
>> From: Greg Trasuk [mailto:trasukg@stratuscom.com]=20
>> Sent: Tuesday, July 10, 2012 4:36 PM
>> To: dev@river.apache.org
>> Subject: Re: Question about LeaseRenewalManager and renewDuration
>>=20
>>=20
>> 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=20
>>> temporary network glitch, it assumes the listener is no longer =
available and cancels the event lease.
>>=20
>> 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.
>>=20
>> 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. =20
>>=20
>> 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.
>>=20
>> Cheers,
>>=20
>> Greg.
>> --
>> Greg Trasuk, President
>> StratusCom Manufacturing Systems Inc. - We use information technology =
to solve business problems on your plant floor.
>> http://stratuscom.com
>>=20
>>=20
>>=20
>=20