|
»
»
« Return to Thread: LE.2.1 Characteristics of a Lease
Re: LE.2.1 Characteristics of a Lease
by Gregg Wonderly-2
::
Rate this Message:
Greg Trasuk wrote:
> On Tue, 2008-07-08 at 13:59, Gregg Wonderly wrote:
>
>> I'm trying to decide at which place, it makes the most since, for renewal
>> failure, to be handled. My basic concern, is that I am providing leases, which
>> are "forever" leases when a client adds a listener for particular kinds of
>> events that the service generates. These leases involve UDP traffic, and are
>> important to allow the server to stop sending traffic when a client goes away.
>>
> In the general case, you need a time-based thread to fire an event at
> the instant the lease expires. As the lease is renewed, you move back
> the time that the expiry event will fire. Could be a periodic 'reaper'
> thread or actually event-based.
The Landlord implementation can do this automatically, if expiry is moved
forward, toward the grantors expiration apon renew, and that expiration fires
when the granted renew interval has expired without another renew. For example,
if the grantor creates a lease, and the Landlord creates a lease management
entry with fields initialized as
endTime = expiry; // The time the lease actually expires
expTime = expiry; // The time that the expiration notification uses for expiry
and then if renew is every called, it does
public long renew( Lease l, long duration ) throws UnknownLeaseException{
LME e = findLeaseEntry( l );
if( e == null )
throw new UnknownLeaseException(e);
long inc = Math.min( duration, MAX_RENEW_INTERVAL );
long now = System.currentTimeMillis();
if( now + inc < e.endTime ) {
expTime = now + inc;
} else {
expTime = endTime;
}
return expTime - System.currentTimeMillis();
}
> 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 two different types of listeners, LeaseStateListener and LeaseListener,
provide different mechanisms to the two different parties.
LeaseListener just tells the "client" that the server can't be contacted for
renewal, and this allows it to find an appropriate resource to recover from this
fact. If the Landlord implementation, refuses the renew the lease, because the
lease has expired, it's not clear to me exactly what to expect.
LeaseStateListener lets the grantor see the activities of the client and
Landlord implementation. The expired() and cancelled() methods definitely tell
you what has happened with the lease, reguarding the time you granted in your
lease creation having expired, and the client canceling the lease. The
renewed() method tells you that the client is renewing the lease.
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.
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@...
> On Tue, 2008-07-08 at 13:59, Gregg Wonderly wrote:
>
>> I'm trying to decide at which place, it makes the most since, for renewal
>> failure, to be handled. My basic concern, is that I am providing leases, which
>> are "forever" leases when a client adds a listener for particular kinds of
>> events that the service generates. These leases involve UDP traffic, and are
>> important to allow the server to stop sending traffic when a client goes away.
>>
> In the general case, you need a time-based thread to fire an event at
> the instant the lease expires. As the lease is renewed, you move back
> the time that the expiry event will fire. Could be a periodic 'reaper'
> thread or actually event-based.
The Landlord implementation can do this automatically, if expiry is moved
forward, toward the grantors expiration apon renew, and that expiration fires
when the granted renew interval has expired without another renew. For example,
if the grantor creates a lease, and the Landlord creates a lease management
entry with fields initialized as
endTime = expiry; // The time the lease actually expires
expTime = expiry; // The time that the expiration notification uses for expiry
and then if renew is every called, it does
public long renew( Lease l, long duration ) throws UnknownLeaseException{
LME e = findLeaseEntry( l );
if( e == null )
throw new UnknownLeaseException(e);
long inc = Math.min( duration, MAX_RENEW_INTERVAL );
long now = System.currentTimeMillis();
if( now + inc < e.endTime ) {
expTime = now + inc;
} else {
expTime = endTime;
}
return expTime - System.currentTimeMillis();
}
> 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 two different types of listeners, LeaseStateListener and LeaseListener,
provide different mechanisms to the two different parties.
LeaseListener just tells the "client" that the server can't be contacted for
renewal, and this allows it to find an appropriate resource to recover from this
fact. If the Landlord implementation, refuses the renew the lease, because the
lease has expired, it's not clear to me exactly what to expect.
LeaseStateListener lets the grantor see the activities of the client and
Landlord implementation. The expired() and cancelled() methods definitely tell
you what has happened with the lease, reguarding the time you granted in your
lease creation having expired, and the client canceling the lease. The
renewed() method tells you that the client is renewing the lease.
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.
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@...
« Return to Thread: LE.2.1 Characteristics of a Lease
| Free embeddable forum powered by Nabble | Forum Help |
