Discussion:
LE.2.1 Characteristics of a Lease
Gregg Wonderly
2008-07-08 17:59:10 UTC
Permalink
I'm trying to understand some of the nuances of Landlord implementation, and the
behavior of the LRM related to my previous post, asking about when
LeaseListener.notify() gets called. I've included the text of LE.2.1 below for
reference.

One of the interesting issues, for me, is that lease renewal, indicates a
continued interest in a resource. The lease grantor, who created the lease,
specified an upper bound on the length of time that the lease was valid. That
entity, also could have specified a LeaseStateListener, to watch "renew" come in.

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.

I'd like for the service to be notified when any particular renewal interval
expires, and I'd like the client to be in charge of what interval it might
request as a max value, while I can configure the maximum that I'm willing to
grant. All of the values are provided by what is in place today.

My issue is that if the client misses a renewal, I want the service to stop
sending events. I can make my Landlord implementation track the grantor's
specified duration initially, but then set the expiration time to the value that
is specified by the renewal so that a sliding window occurs.

My issue is that this seems to invalidate my implementation, because of the
text, "However, when renewing a lease the grantor cannot, unless explicitly
requested to do so, shorten the duration of the lease so that it expires before
it would have if it had not been renewed."

So, should I make the LeaseStateListener deal with missing renews?

It seems like renew is worthless, if it doesn't represent an opportunity for
expiry to occur, when renews are missing.

Gregg Wonderly


---------------------------------------------------------------------------

LE.2.1 Characteristics of a Lease

There are a number of characteristics that are important for understanding what
a lease is and when it is appropriate to use one. Among these characteristics are:

* A lease is a time period during which the grantor of the lease ensures
(to the best of the grantor's abilities) that the holder of the lease will have
access to some resource. The time period of the lease can be determined solely
by the lease grantor, or can be a period of time that is negotiated between the
holder of the lease and the grantor of the lease. Duration negotiation need not
be multi-round; it often suffices for the requestor to indicate the time desired
and the grantor to return the actual time of grant.

* During the period of a lease, a lease can be cancelled by the entity
holding the lease. Such a cancellation allows the grantor of the lease to clean
up any resources associated with the lease and obliges the grantor of the lease
to not take any action involving the lease holder that was part of the agreement
that was the subject of the lease.

* A lease holder can request that a lease be renewed. The renewal period
can be for a different time than the original lease, and is also subject to
negotiation with the grantor of the lease. The grantor may renew the lease for
the requested period or a shorter period or may refuse to renew the lease at
all. However, when renewing a lease the grantor cannot, unless explicitly
requested to do so, shorten the duration of the lease so that it expires before
it would have if it had not been renewed. A renewed lease is just like any other
lease and is itself subject to renewal.

* A lease can expire. If a lease period has elapsed with no renewals, the
lease expires, and any resources associated with the lease may be freed by the
lease grantor. Both the grantor and the holder are obliged to act as though the
leased agreement is no longer in force. The expiration of a lease is similar to
the cancellation of a lease, except that no communication is necessary between
the lease holder and the lease grantor.

Leasing is part of a programming model for building reliable distributed
applications. In particular, leasing is a way of ensuring that a uniform
response to failure, forgetting, or disinterest is guaranteed, allowing
agreements to be made that can then be forgotten without the possibility of
unbounded resource consumption, and providing a flexible mechanism for
duration-based agreement.

--------------------------------------------------------------------------
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 ***@java.sun.com
Greg Trasuk
2008-07-08 18:18:56 UTC
Permalink
Post by Gregg Wonderly
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.

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 renewal is a separate issue from expiring the leases and freeing the
resources.
--
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 ***@java.sun.com
Gregg Wonderly
2008-07-08 19:33:23 UTC
Permalink
Post by Greg Trasuk
Post by Gregg Wonderly
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();
}
Post by Greg Trasuk
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.
Post by Greg Trasuk
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 ***@java.sun.com
Greg Trasuk
2008-07-08 20:56:48 UTC
Permalink
Post by Gregg Wonderly
<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>
Post by Gregg Wonderly
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.
Post by Gregg Wonderly
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
--
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 ***@java.sun.com
Bob Scheifler
2008-07-08 19:25:03 UTC
Permalink
Post by Gregg Wonderly
My issue is that if the client misses a renewal, I want the service to
stop sending events.
That's what it should do.
Post by Gregg Wonderly
My issue is that this seems to invalidate my implementation, because of
the text, "However, when renewing a lease the grantor cannot, unless
explicitly requested to do so, shorten the duration of the lease so that
it expires before it would have if it had not been renewed."
That text means that if the existing expiration time is E0, and the
new expiration time requested in the renewal is E1, and if E1 >= E0,
then the granted expiration time E must also be >= E0. If a lease's
expiration time is reached without a renewal, the lease must still
expire.

- Bob

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-08 19:50:50 UTC
Permalink
Post by Bob Scheifler
Post by Gregg Wonderly
My issue is that if the client misses a renewal, I want the service to
stop sending events.
That's what it should do.
Post by Gregg Wonderly
My issue is that this seems to invalidate my implementation, because
of the text, "However, when renewing a lease the grantor cannot,
unless explicitly requested to do so, shorten the duration of the
lease so that it expires before it would have if it had not been
renewed."
That text means that if the existing expiration time is E0, and the
new expiration time requested in the renewal is E1, and if E1 >= E0,
then the granted expiration time E must also be >= E0. If a lease's
expiration time is reached without a renewal, the lease must still
expire.
My reading says that E0 would always be == to time that was passed to
LeaseFactory.newLease(). Maybe my previous email with more specifics, reveals
more about what I am trying to get at?

That text is also a little bit troubling from the perspective of the Landlord
implementation. The callee of LeaseFactory.newLease() never has the opportunity
to extend or shorten the lease, unless it also has knowledge of the Landlord
that the LeaseFactory was created with. Is it intended that lease grantors and
resources be that close together in binding of leases to lease expiration?

Maybe I am trying to keep them too far apart, so that the Landlord.renew() call
can't be influenced by the resource owner? The LeaseStateListener seems to be
the hook for learning about renewal requests, not explicit relationships between
the Landlord implementation and the resource.

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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-08 21:11:18 UTC
Permalink
Post by Gregg Wonderly
Post by Bob Scheifler
Post by Gregg Wonderly
My issue is that if the client misses a renewal, I want the service
to stop sending events.
That's what it should do.
Post by Gregg Wonderly
My issue is that this seems to invalidate my implementation, because
of the text, "However, when renewing a lease the grantor cannot,
unless explicitly requested to do so, shorten the duration of the
lease so that it expires before it would have if it had not been
renewed."
That text means that if the existing expiration time is E0, and the
new expiration time requested in the renewal is E1, and if E1 >= E0,
then the granted expiration time E must also be >= E0. If a lease's
expiration time is reached without a renewal, the lease must still
expire.
My reading says that E0 would always be == to time that was passed to
LeaseFactory.newLease().
I think the duality between durations and expirations may be tripping
you up here. Say its 6 pm and you are a client holding a lease set to
expire at 8 pm. You call renew() passing 14,400,000 (which works out to
4 hours), because 14,400,000 ms is longer than the current duration
(7,200,000 ms) the granter can't change the expiration time to 7 pm (or
7:59 pm) because that would shorten the current duration and you asked
for a renewal that was longer than the current duration.
Post by Gregg Wonderly
Maybe my previous email with more specifics,
reveals more about what I am trying to get at?
I can't find your previous message, do you have a pointer?
Post by Gregg Wonderly
That text is also a little bit troubling from the perspective of the
Landlord implementation. The callee of LeaseFactory.newLease() never
has the opportunity to extend or shorten the lease, unless it also has
knowledge of the Landlord that the LeaseFactory was created with. Is it
intended that lease grantors and resources be that close together in
binding of leases to lease expiration?
Maybe I am trying to keep them too far apart, so that the
Landlord.renew() call can't be influenced by the resource owner? The
LeaseStateListener seems to be the hook for learning about renewal
requests, not explicit relationships between the Landlord implementation
and the resource.
My assumption as always been that the caller of LeaseFactory.newLease()
is the Landlord.

[where is LeaseStateListener? I see LeaseListener, but that is part of
the LRM's interface, which is on the client side, not sure what that has
to do with Landlords].
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-08 22:41:11 UTC
Permalink
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
Post by Bob Scheifler
Post by Gregg Wonderly
My issue is that if the client misses a renewal, I want the service
to stop sending events.
That's what it should do.
Post by Gregg Wonderly
My issue is that this seems to invalidate my implementation, because
of the text, "However, when renewing a lease the grantor cannot,
unless explicitly requested to do so, shorten the duration of the
lease so that it expires before it would have if it had not been
renewed."
That text means that if the existing expiration time is E0, and the
new expiration time requested in the renewal is E1, and if E1 >= E0,
then the granted expiration time E must also be >= E0. If a lease's
expiration time is reached without a renewal, the lease must still
expire.
My reading says that E0 would always be == to time that was passed to
LeaseFactory.newLease().
I think the duality between durations and expirations may be tripping
you up here. Say its 6 pm and you are a client holding a lease set to
expire at 8 pm. You call renew() passing 14,400,000 (which works out to
4 hours), because 14,400,000 ms is longer than the current duration
(7,200,000 ms) the granter can't change the expiration time to 7 pm (or
7:59 pm) because that would shorten the current duration and you asked
for a renewal that was longer than the current duration.
I am becomming confused by these responses because I am thinking that there are
two time periods involved. The end lease expiration that was granted by
LeaseFactory.newLease()'s activities (and the Landlord impl), and then the
requested renewal durations, which can only span the time period between the
time the lease was created and the time that the Landlord returned as the
expiration time.

Am I missing something? Is it possible for a lease renewal to extend the expiry
time beyond what the granter returned via Lease.getExpiration()'s value at the
time the Lease is created?
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
Maybe my previous email with more specifics, reveals more about what I
am trying to get at?
I can't find your previous message, do you have a pointer?
It may just be slow arriving on the list.
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
That text is also a little bit troubling from the perspective of the
Landlord implementation. The callee of LeaseFactory.newLease() never
has the opportunity to extend or shorten the lease, unless it also has
knowledge of the Landlord that the LeaseFactory was created with. Is
it intended that lease grantors and resources be that close together
in binding of leases to lease expiration?
Maybe I am trying to keep them too far apart, so that the
Landlord.renew() call can't be influenced by the resource owner? The
LeaseStateListener seems to be the hook for learning about renewal
requests, not explicit relationships between the Landlord
implementation and the resource.
My assumption as always been that the caller of LeaseFactory.newLease()
is the Landlord.
The Landlord provides some interface for external users to create leases right?
So how would the caller of that mechanism adjust the ultimate expiry time, if
they wanted to extend it "forever" based on the fact that the client is still
calling renew and things still seem to be sane?
Post by John McClain - Sun Microsystems, Inc.
[where is LeaseStateListener? I see LeaseListener, but that is part of
the LRM's interface, which is on the client side, not sure what that has
to do with Landlords].
Ahha, I forgot that I invented LeaseStateListener. My Landlord implementation
accepts an implementation of this when you ask it for a lease. It notifies you
of expired(), cancelled() and renewed() events that it gets from external calls.

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 ***@java.sun.com
Bob Scheifler
2008-07-09 00:02:13 UTC
Permalink
Post by Gregg Wonderly
Is it possible for a lease renewal to extend
the expiry time beyond what the granter returned via
Lease.getExpiration()'s value at the time the Lease is created?
Yes, that's pretty much the purpose of lease renewal.

- Bob

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-09 15:24:30 UTC
Permalink
Post by Bob Scheifler
Is it possible for a lease renewal to extend the expiry time beyond
what the granter returned via Lease.getExpiration()'s value at the
time the Lease is created?
Yes, that's pretty much the purpose of lease renewal.
Okay, so a lease, is open ended. So the only way to expire the lease, is to
always return a relatively short duration in the granted leases initial
expiration. It is possible, for an upper bound to be enforced by the Landlord,
but practically, that's not what should be done in most cases, right?

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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-09 18:49:49 UTC
Permalink
Post by Gregg Wonderly
Post by Bob Scheifler
Is it possible for a lease renewal to extend the expiry time beyond
what the granter returned via Lease.getExpiration()'s value at the
time the Lease is created?
Yes, that's pretty much the purpose of lease renewal.
Okay, so a lease, is open ended. So the only way to expire the lease,
is to always return a relatively short duration in the granted leases
initial expiration.
I wouldn't get overly focused on the initial expiration, if I grant an
initial expiration 5 minutes in the future, and on the first renewal
request I grant a renewal 5000 years in the future I am in the pretty
much the same situation as if I granted a 5000 year lease initially. I
think in all the lease granting code I have written or seen the policy
used for the initial lease grant is the same as the policy used for
renewals (and once renewal is granted, any previous expiration time is
forgotten).
Post by Gregg Wonderly
It is possible, for an upper bound to be enforced
by the Landlord, but practically, that's not what should be done in most
cases, right?
I would say no. My experience is that most lease grantors (in my mind
grantor == Landlord) *do* enforce an upper bound. The one exception that
comes to mind is Outrigger in the case of entry leases. By default
Outrigger is willing to grant Lease.FOREVER for Entry leases (but not
event leases).

Does this help?
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-09 19:20:08 UTC
Permalink
Post by John McClain - Sun Microsystems, Inc.
Does this help?
I think I've got all the ins and outs figure out now. I'm evaluating my changes
to my Landlord today and it should be working as needed. We were seeing odd
lease expiration behavior because I was assuming that the initial lease value
was separate from what was driving LRMs renews. My renew() implementation is
now essentially:

public long renew( Uuid uuid, long renewDuration )
throws UnknownLeaseException {
LeaseEntryHolder le;
le = (LeaseEntryHolder)knownMap.get( uuid );
if( le == null ) {
throw new UnknownLeaseException(
uuid+": lease not found" );
}
long inc = Math.min( maxLeaseTime,
Math.max( renewDuration, minLeaseTime ) );
long now = System.currentTimeMillis();

// Remove from time ordered list
removeEntry( le );

// If we can advance the lease do that

// Insert into time ordered list
insertEntry( le );

// Return granted duration.
return le.expTime - now;
}

The fragment:

if( le.expTime < now + inc ) {
le.expTime = now + inc;
}

keeps the lease expiration from going backwards. If the initial lease has an
expiration, one hour into the future, and a renewal is attempted for 5 mins into
the future, inside of the expiration window, I don't want to backup the
expiration, based on what I read in the spec and my interpretation of Bob's
posting yesterday.


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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-09 20:51:19 UTC
Permalink
Post by Gregg Wonderly
Post by John McClain - Sun Microsystems, Inc.
Does this help?
I think I've got all the ins and outs figure out now. I'm evaluating my
changes to my Landlord today and it should be working as needed. We
were seeing odd lease expiration behavior because I was assuming that
the initial lease value was separate from what was driving LRMs renews.
public long renew( Uuid uuid, long renewDuration )
throws UnknownLeaseException {
LeaseEntryHolder le;
le = (LeaseEntryHolder)knownMap.get( uuid );
if( le == null ) {
throw new UnknownLeaseException(
uuid+": lease not found" );
}
long inc = Math.min( maxLeaseTime,
Math.max( renewDuration, minLeaseTime ) );
Not sure what the Math.max is doing here, if someone asks for a 1 s
lease, you shouldn't (by spec) be giving them a 5 minute one.
Post by Gregg Wonderly
long now = System.currentTimeMillis();
// Remove from time ordered list
removeEntry( le );
// If we can advance the lease do that
// Insert into time ordered list
insertEntry( le );
// Return granted duration.
return le.expTime - now;
}
if( le.expTime < now + inc ) {
le.expTime = now + inc;
}
keeps the lease expiration from going backwards. If the initial lease
has an expiration, one hour into the future, and a renewal is attempted
for 5 mins into the future, inside of the expiration window, I don't
want to backup the expiration, based on what I read in the spec and my
interpretation of Bob's posting yesterday.
It's not that the expiration can't go backwards, it is that it can only
go backwards if the client asks for a duration that is sooner than the
current expiration. So if after 5 minutes they ask for a renewal of an
hour you have to give them at least the current expiration, but if after
5 minutes they ask for a 10 minute renewal, you can't give them a
renewal further than 10 minutes into the future.

Also, don't forget to handle Lease.ANY....
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-09 21:48:12 UTC
Permalink
Post by John McClain - Sun Microsystems, Inc.
Not sure what the Math.max is doing here, if someone asks for a 1 s
lease, you shouldn't (by spec) be giving them a 5 minute one.
Okay, I'll remove the Math.max usage if that is not an expected behavior. I
guess I missed seeing that in the spec.
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
long now = System.currentTimeMillis();
// Remove from time ordered list
removeEntry( le );
// If we can advance the lease do that
// Insert into time ordered list
insertEntry( le );
// Return granted duration.
return le.expTime - now;
}
if( le.expTime < now + inc ) {
le.expTime = now + inc;
}
keeps the lease expiration from going backwards. If the initial lease
has an expiration, one hour into the future, and a renewal is
attempted for 5 mins into the future, inside of the expiration window,
I don't want to backup the expiration, based on what I read in the
spec and my interpretation of Bob's posting yesterday.
It's not that the expiration can't go backwards, it is that it can only
go backwards if the client asks for a duration that is sooner than the
current expiration. So if after 5 minutes they ask for a renewal of an
hour you have to give them at least the current expiration, but if after
5 minutes they ask for a 10 minute renewal, you can't give them a
renewal further than 10 minutes into the future.
Okay, I'm not sure I see the scenario where this wouldn't be tree if I remove
the if above and just always do

le.expTime = now + inc;

That allows the client to do whatever they want with the lease expiry.
Post by John McClain - Sun Microsystems, Inc.
Also, don't forget to handle Lease.ANY....
Ooops, right, I changed the 'inc' assignment to

long inc = Math.min( maxLeaseDuration,
renewDuration == Lease.ANY ?
maxLeaseDuration : renewDuration );

Thanks for the help all!

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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-10 13:51:06 UTC
Permalink
[...]
Post by Gregg Wonderly
Post by John McClain - Sun Microsystems, Inc.
It's not that the expiration can't go backwards, it is that it can
only go backwards if the client asks for a duration that is sooner
than the current expiration. So if after 5 minutes they ask for a
renewal of an hour you have to give them at least the current
expiration, but if after 5 minutes they ask for a 10 minute renewal,
you can't give them a renewal further than 10 minutes into the future.
Okay, I'm not sure I see the scenario where this wouldn't be tree if I
remove the if above and just always do
le.expTime = now + inc;
Your are right, it is not a problem if maxLeaseDuration is fixed ( it is
an issue for us because in most our implementations maxLeaseDuration is
configurable and thus might change over a lease's lifetime, Reggie takes
this a steep further and dynamically varies the max lease duration it
is willing to grant based on load).
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-10 15:05:11 UTC
Permalink
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
Okay, I'm not sure I see the scenario where this wouldn't be tree if I
remove the if above and just always do
le.expTime = now + inc;
Your are right, it is not a problem if maxLeaseDuration is fixed ( it is
an issue for us because in most our implementations maxLeaseDuration is
configurable and thus might change over a lease's lifetime, Reggie takes
this a steep further and dynamically varies the max lease duration it
is willing to grant based on load).
So do you think that there would be a need for a Landlord implementation that
encompassed all of these different aspects to help people who need to create
leases have an easier time getting started? :-)

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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-10 20:37:52 UTC
Permalink
Post by Gregg Wonderly
Post by John McClain - Sun Microsystems, Inc.
Post by Gregg Wonderly
Okay, I'm not sure I see the scenario where this wouldn't be tree if
I remove the if above and just always do
le.expTime = now + inc;
Your are right, it is not a problem if maxLeaseDuration is fixed ( it
is an issue for us because in most our implementations
maxLeaseDuration is configurable and thus might change over a lease's
lifetime, Reggie takes this a steep further and dynamically varies
the max lease duration it is willing to grant based on load).
So do you think that there would be a need for a Landlord implementation
that encompassed all of these different aspects to help people who need
to create leases have an easier time getting started? :-)
Post by John McClain - Sun Microsystems, Inc.
What's going on here is that the Landlord interface isn't defining
some policy object, but just the network protocol (in the Jini sense)
that LandlordLeases use to callback to the server, we don't really expect
implementations of the Landord interface that are standalone objects.
Okay. It seems that many of the concepts of lease life cycle are
repetitive and variations on renew() might be the biggest difference,
overall. So, I have a standalone class, that I pass a Configuration to
etc. I'm interested in getting this stuff right, once, in one place,
and dealing with nuances in a general way I guess. I'll look some more
at the various JTSK services use of Landlord for any other "detail" I
can learn more about.
FWIW, a bit of background

When we did the initial analysis (~10 years ago - it could be dated...)
we decided that in our context[*] it wasn't practical to design Landlord
as the sort of standalone class you describe. When you get into the
internals of a service's lease management you intersect with its
approach to synchronization, persistence, and resource lookup, and the
services in the starter kit diverged quite a bit in these areas. Instead
we focused the landlord package (then com.sun.jini.lease.landlord) on
providing an implementation of net.jini.core.lease.Lease, LandlordLease,
the Landlord interface was introduced for LandlordLease's sake, it
doesn't help the service implementation directly.

We did provide a few bits of code to help the server side of the
implementation, in particular FixLeasePeriodPolicy embodies a simple
(and for most our services sufficient) policy for granting lease periods
while also capturing some easy to forget details around handing
Lease.ANY, overflows, and not letting renewals go back in time unless
the client asks. LeasePeriodPolicy was introduced so we could make lease
period granting polices plugable. LandlordUtil & LocalLandlord just
capture a bit of structural code for handling batch renew and cancel.
LeaseFactory is just a convent way to construct LandlordLeases in the
context 2.0 security model - so again it is just a bit of structure
captured in a utility.

[*]"in our context" is key, if you were developing a higher level
framework for service development that assumed/provided schemes
persistence/concurrency/resource lookup then you could provide a
standalone object, though I expect at that point you probably keep going
and make most of the lease handling invisible to the developer, maybe
only exposing an "isExpired" method and a place to register a
LeasePeriodPolicy.
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Bob Scheifler
2008-07-10 00:10:31 UTC
Permalink
Post by Gregg Wonderly
Okay, so a lease, is open ended.
Many leases are, but a lease doesn't have to be open ended.
Your policy could for example be to hand out an initial 30 minute lease,
and then deny all attempts to renew past that original expiration.
Or your policy could be to hand out an initial 5 minute lease,
and then honor renewals as long as they don't extend the
expiration more than 6 hours past the original expiration.

- Bob

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-10 05:04:25 UTC
Permalink
Post by Bob Scheifler
Post by Gregg Wonderly
Okay, so a lease, is open ended.
Many leases are, but a lease doesn't have to be open ended.
Your policy could for example be to hand out an initial 30 minute lease,
and then deny all attempts to renew past that original expiration.
Or your policy could be to hand out an initial 5 minute lease,
and then honor renewals as long as they don't extend the
expiration more than 6 hours past the original expiration.
Okay, but since none of this is visible as part of the "API" that exists from
LeaseFactory/Landlord's perspective, I believe this is a Landlord implementation
detail. That's why I said before, that the Landlord might be more integrated
into the granter than the interface alludes to, so that the granter can either
be a part of what renew() decides, or provide additional parameters when
creating an instance of a particular Landlord implementation.

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 ***@java.sun.com
Bob Scheifler
2008-07-10 13:53:43 UTC
Permalink
Post by Gregg Wonderly
Post by Bob Scheifler
Many leases are, but a lease doesn't have to be open ended.
Okay, but since none of this is visible as part of the "API" that exists
from LeaseFactory/Landlord's perspective, I believe this is a Landlord
implementation detail.
No, my statements are generically about leases, completely ignoring
what the landlord package does or doesn't do (since I don't even
remember off-hand what it does).

- Bob

--------------------------------------------------------------------------
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 ***@java.sun.com
John McClain - Sun Microsystems, Inc.
2008-07-10 14:50:29 UTC
Permalink
Post by Gregg Wonderly
Post by Bob Scheifler
Post by Gregg Wonderly
Okay, so a lease, is open ended.
Many leases are, but a lease doesn't have to be open ended.
Your policy could for example be to hand out an initial 30 minute lease,
and then deny all attempts to renew past that original expiration.
Or your policy could be to hand out an initial 5 minute lease,
and then honor renewals as long as they don't extend the
expiration more than 6 hours past the original expiration.
Okay, but since none of this is visible as part of the "API" that exists
from LeaseFactory/Landlord's perspective, I believe this is a Landlord
implementation detail. That's why I said before, that the Landlord
might be more integrated into the granter than the interface alludes to,
so that the granter can either be a part of what renew() decides, or
provide additional parameters when creating an instance of a particular
Landlord implementation.
As I said before, the Landlord generally *is* (as opposed to "part of")
the grantor - so a tight integration is expected. If you look at
Outrigger, OutriggerServer (which defines the private protocol between
the Outrigger's proxy and the server) extends
com.sun.jini.landlord.Landlord, and OutriggerServerImpl implements the 4
methods of the Landlord interface directly, it doesn't delegate them
to some other object. You don't plug an object implementing Landlord
into Outrigger, Outrigger is a Landlord.

What's going on here is that the Landlord interface isn't defining some
policy object, but just the network protocol (in the Jini sense) that
LandlordLeases use to callback to the server, we don't really expect
implementations of the Landord interface that are standalone objects.
--
John McClain ***@sun.com
Sun Microsystems, Inc.
Burlington, MA

And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.

- David Brooks

--------------------------------------------------------------------------
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 ***@java.sun.com
Gregg Wonderly
2008-07-10 15:12:45 UTC
Permalink
Post by John McClain - Sun Microsystems, Inc.
What's going on here is that the Landlord interface isn't defining some
policy object, but just the network protocol (in the Jini sense) that
LandlordLeases use to callback to the server, we don't really expect
implementations of the Landord interface that are standalone objects.
Okay. It seems that many of the concepts of lease life cycle are repetitive and
variations on renew() might be the biggest difference, overall. So, I have a
standalone class, that I pass a Configuration to etc. I'm interested in getting
this stuff right, once, in one place, and dealing with nuances in a general way
I guess. I'll look some more at the various JTSK services use of Landlord for
any other "detail" I can learn more about.

Thanks for your dialog and feedback folks.

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 ***@java.sun.com
Gregg Wonderly
2008-07-09 15:49:59 UTC
Permalink
Post by Bob Scheifler
Is it possible for a lease renewal to extend the expiry time beyond
what the granter returned via Lease.getExpiration()'s value at the
time the Lease is created?
Yes, that's pretty much the purpose of lease renewal.
As another follow up, it seems to me that there is a lot of confusing
terminology rolled into the lease javadocs. I didn't seem to find a nice
explanation of the usage patterns that would of allowed me to find out the
information that I've spent a couple of days of discovery on.

I found it confusing at times to try and understand the various time values and
their usages. The absolute time used to create a lease (LeaseFactory.newLease()
most likely used), created the view for me, that the caller makes the decision
of when the lease ultimately expires, absolutely by passing some precise time.
This led me to believe that a forever lease, required the granter to use
Lease.FOREVER as the LeaseFactory.newLease() argument, for any lease that was
open ended. I thought that was a bit odd, and that's why I posted to the list.

The lease granter didn't appear to get any chance to "cap" the time on the
lease, except through this argument to LeaseFactory.newLease(). I think it
would be great to have a little more visibility of the relationship of expiry,
vs the requested lease duration in the javadocs.

Is there a pattern, or something else done normally that makes this all a little
more obvious? LeaseRenewalManager.renewUntil()'s two different signatures allow
it to either get an explicit renewal interval, or choose one based on the leases
expiry and renew returned duration. But, it's not clear how these times would
relate to the Lease granters used time in creating the lease.

The client gets to say, explicitly how long it is interested, while the granter,
seems to have that with the LeaseFactory.newLease() argument, but not actually,
because Landlord impls can accept renewals forever. So, a granter has to
provide the Landlord impl as a closely associated implementation detail if it
wants to manage a cap on the lease. The Landlord interface doesn't provide such
an API, so probably a more specialized implementation would be used in such cases.

When I've just used leases related to transactions and
ServiceRegistrar.notify(), the LRM provided me what I thought was an appropriate
mechanism as a client. Implementing a Landlord, has revealed some things that I
just didn't grasp well before I guess. I just need open ended leases, but I
keep trying to figure out how 'capped' leases would be implemented, and I think
it's a Landlord implementation detail, not a LeaseFactory.newLease() argument
detail.

Perhaps newLease() documentation could help with this by discussing more about
the expiration argument. It calls in the initial expiration time. With some
more thought about the words and what I know, the text there is probably
sufficient for the informed, but perhaps somewhat terse for those trying to
understand how Landlord should use that value.

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 ***@java.sun.com
Continue reading on narkive:
Loading...