LE.2.1 Characteristics of a Lease

[Gregg Wonderly-2]

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 listserv@...

[Greg Trasuk]

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.

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 listserv@...

[Bob Scheifler]

> My issue is that if the client misses a renewal, I want the service to
> stop sending events.

That's what it should do.

> 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 listserv@...

[Gregg Wonderly-2]

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@...

[Gregg Wonderly-2]

Bob Scheifler wrote:

>> My issue is that if the client misses a renewal, I want the service to
>> stop sending events.
>
> That's what it should do.
>
>> 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 listserv@...

[Greg Trasuk]

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@...

[John McClain - Sun Microsystems, Inc.]

Gregg Wonderly wrote:

> Bob Scheifler wrote:
>>> My issue is that if the client misses a renewal, I want the service
>>> to stop sending events.
>>
>> That's what it should do.
>>
>>> 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.


> 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?

> 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 john.mcclain@...
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 listserv@...

[Gregg Wonderly-2]

John McClain - Sun Microsystems, Inc. wrote:

> Gregg Wonderly wrote:
>> Bob Scheifler wrote:
>>>> My issue is that if the client misses a renewal, I want the service
>>>> to stop sending events.
>>>
>>> That's what it should do.
>>>
>>>> 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?

>> 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.

>> 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?

> [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 listserv@...

[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.

- 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 listserv@...

[Gregg Wonderly-2]

Bob Scheifler wrote:
>> 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 listserv@...

[Gregg Wonderly-2]

Bob Scheifler wrote:
>> 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 listserv@...

[John McClain - Sun Microsystems, Inc.]

Gregg Wonderly wrote:

> Bob Scheifler wrote:
>>> 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).

> 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 john.mcclain@...
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 listserv@...

[Gregg Wonderly-2]

John McClain - Sun Microsystems, Inc. wrote:
> 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 listserv@...

[John McClain - Sun Microsystems, Inc.]

Gregg Wonderly wrote:

> John McClain - Sun Microsystems, Inc. wrote:
>> 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 ) );

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.

>     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.

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 john.mcclain@...
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 listserv@...