|
»
»
« Return to Thread: LE.2.1 Characteristics of a Lease
Re: LE.2.1 Characteristics of a Lease
by Greg Trasuk
::
Rate this Message:
On Tue, 2008-07-08 at 15:33, Gregg Wonderly wrote:
> Greg Trasuk wrote:
> > On Tue, 2008-07-08 at 13:59, Gregg Wonderly wrote:
> >
> ><snip>
>
> > In the common case where you are generating periodic events, I've always
> > found it reasonable to just check if the lease is expired prior to
> > sending out the event notification.
>
> The lease is forever, because the client gets the lease as the return from
> adding a listener, very much like ServiceRegistrar.notify() returns a lease.
> The difference is that the ServiceRegistrar endpoint, in the typical use, is a
> TCP endpoint, and thus can learn of the client not being reachable. But, I am
> using UDP endpoints (in a smart proxy that hides the UDP), and thus I need a
> different reachability check.
>
> > The renewal is a separate issue from expiring the leases and freeing the
> > resources.
><snip>
> The mechanism that I am looking for leases to provide is a form of "keepalive".
> What the spec says, is that a lease is precisely for the time that the grantor
> creates it to expire at. If the lifetime of the associated resource user, is
> unbounded (grantor allowed/used Lease.FOREVER), the LeaseStateListener.expired()
> doesn't seem to have a function in the lifecycle of the lease.
>
Hold on a minute - you're granting leases that last forever?
I've always taken the Lease.FOREVER as the requester's way of saying "I
want this lease to last as long as you'll allow". The grantor gets to
choose the lease length. So the grantor would choose a lease length
that represents the maximum amount of time it is willing to hold the
resources in the absence of a renewal. I can't imagine a grantor
actually giving out a lease that lasted forever. In that case, the
requester would never need to renew, correct?
So, I would take the lease duration as being the amount of time you're
willing to send out your UDP packets if the recipient has "dropped off
the grid". Or how long you're willing to attempt to deliver
notifications in the face of what might be a temporary network failure.
(1)
If the requester wants a lease that effectively lasts forever, that's
his problem, for which he hands the lease to a LeaseRenewalManager.
(1) - By the same token, I've always thought that the lease was a
commitment to keep trying to deliver the notifications, even if
connectivity seemed to be gone. Remember that the listener might have
been a smart proxy or might be using a protocol that could repair itself
(or might be someday) and don't assume that because we got an exception
that we should stop sending the notifications. So I've always
implemented a policy that we keep sending events, and getting
exceptions, until the lease expires.
> In this case, the grantor appears to need to use LeaseStateListener.renewed() as
> a lifecycle driver, instead of allow LeaseStateListener.expired() to be used for
> error conditions when the client fails to renew.
>
> If that's the intended usage, I can deal with that, but I'm just trying to
> understand what I see in the spec in complete detail.
>
> Gregg Wonderly
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@...--
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...
> Greg Trasuk wrote:
> > On Tue, 2008-07-08 at 13:59, Gregg Wonderly wrote:
> >
> ><snip>
>
> > In the common case where you are generating periodic events, I've always
> > found it reasonable to just check if the lease is expired prior to
> > sending out the event notification.
>
> The lease is forever, because the client gets the lease as the return from
> adding a listener, very much like ServiceRegistrar.notify() returns a lease.
> The difference is that the ServiceRegistrar endpoint, in the typical use, is a
> TCP endpoint, and thus can learn of the client not being reachable. But, I am
> using UDP endpoints (in a smart proxy that hides the UDP), and thus I need a
> different reachability check.
>
> > The renewal is a separate issue from expiring the leases and freeing the
> > resources.
>
> The mechanism that I am looking for leases to provide is a form of "keepalive".
> What the spec says, is that a lease is precisely for the time that the grantor
> creates it to expire at. If the lifetime of the associated resource user, is
> unbounded (grantor allowed/used Lease.FOREVER), the LeaseStateListener.expired()
> doesn't seem to have a function in the lifecycle of the lease.
>
Hold on a minute - you're granting leases that last forever?
I've always taken the Lease.FOREVER as the requester's way of saying "I
want this lease to last as long as you'll allow". The grantor gets to
choose the lease length. So the grantor would choose a lease length
that represents the maximum amount of time it is willing to hold the
resources in the absence of a renewal. I can't imagine a grantor
actually giving out a lease that lasted forever. In that case, the
requester would never need to renew, correct?
So, I would take the lease duration as being the amount of time you're
willing to send out your UDP packets if the recipient has "dropped off
the grid". Or how long you're willing to attempt to deliver
notifications in the face of what might be a temporary network failure.
(1)
If the requester wants a lease that effectively lasts forever, that's
his problem, for which he hands the lease to a LeaseRenewalManager.
(1) - By the same token, I've always thought that the lease was a
commitment to keep trying to deliver the notifications, even if
connectivity seemed to be gone. Remember that the listener might have
been a smart proxy or might be using a protocol that could repair itself
(or might be someday) and don't assume that because we got an exception
that we should stop sending the notifications. So I've always
implemented a policy that we keep sending events, and getting
exceptions, until the lease expires.
> In this case, the grantor appears to need to use LeaseStateListener.renewed() as
> a lifecycle driver, instead of allow LeaseStateListener.expired() to be used for
> error conditions when the client fails to renew.
>
> If that's the intended usage, I can deal with that, but I'm just trying to
> understand what I see in the spec in complete detail.
>
> Gregg Wonderly
>
> --------------------------------------------------------------------------
> Getting Started: http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site: http://jini.org
> jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing: email "signoff JINI-USERS" to listserv@...
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com
--------------------------------------------------------------------------
Getting Started: http://www.jini.org/wiki/Category:Getting_Started
Community Web Site: http://jini.org
jini-users Archive: http://archives.java.sun.com/archives/jini-users.html
Unsubscribing: email "signoff JINI-USERS" to listserv@...
« Return to Thread: LE.2.1 Characteristics of a Lease
| Free embeddable forum powered by Nabble | Forum Help |
