On 10/25/2010 10:50 AM, Greg Trasuk wrote:
On Mon, 2010-10-25 at 12:15, Patricia Shanahan wrote:
I've made some progress on one form of failure, a resource remaining
available after its lease was scheduled to expire.
If the test pauses, e.g due to an inserted Thread.sleep, between
creating the lease and probing it for the first time, the test passes.
The effect of either of these actions is to delay the probe until after
the lease has expired. Incidentally, hooking up to the Eclipse debugger
was very helpful in discovering this behavior. The first indication was
when I spent a few minutes investigating at a breakpoint, let it
continue, and the test passed.
If the test gets to the probe point before the lease is due to expire,
it goes into a polling loop. No matter how long it stays in the polling
loop, the lease does not expire. Somehow, the probe loop has the effect
of preventing expiration.
What is the "probe code" ? How exactly does it determine that the lease
is still alive?
It calls this method:
protected boolean isAvailable() throws TestException {
try {
final Lease x = space.write(aEntry, resource, 1000);
//addOutriggerLease(x, true);
} catch (TransactionException e) {
// This is ok...probably means it is a bad transactions
return false;
} catch (Exception e) {
throw new TestException("Testing for availability", e);
}
return true;
}
(I've slightly simplified the code, as part of a general attempt to
comment out anything that is not required to reproduce the problem.)
space is a JavaSpace. The objective seems to be to detect whether the
Transaction, resource, remains available. It was originally requested
with a one minute lease duration, and it seems to have got it, "aprox
duration:59991"
If the isAvailable method is called even once before the scheduled
expiration of the resource lease, it will go on returning true. Repeated
calls are not needed - a single early call is sufficient. I've tested
that through a half hour sleep between two calls.
If the first call to this method is after the scheduled expiration of
the resource lease, it returns false.
The JavaSpace is implemented by OutriggerServerImpl. This print call in
its public long[] write(EntryRep rep, Transaction tr, long lease) method:
System.err.printf("XXXpats: Write of rep %s, tr %s, lease %d at %d%n",
rep, tr, lease, System.currentTimeMillis());
reports:
XXXpats: Write of rep
EntryRep[com.sun.jini.test.share.UninterestingEntry], tr
net.jini.core.transaction.server.ServerTransaction
[manager=com.sun.jini.mahalo.txnmgrproxy$constrainabletxnmgrpr...@2b6ad6ff,
id=-6728796543664280839], lease 1000 at 1288065446700
I would like to understand the rules for lease expiration. What actions
should extend a lease?
lease.renew(long duration);
Is the lease manager required to expire it on
schedule? (Even if it is not required to expire the lease I still need
to find out whether the non-expiration is deliberate design or due to a
bug.)
Do you mean the landlord (i.e. the grantor of the lease), or the
LeaseRenewalManager object (which automatically renews leases on behalf
of a lessor)?
The owner of the resource does not need to expire it on a time schedule;
it could expire the lease at some future point that is a convenient run
time (like the next time the service happens to be accessed).
Conceptually, the lease is entirely for the convenience of the lessor;
expiry means that the client is no longer interested in the resource, so
the client's resource allocation can be freed.
In any case, specs would be at:
http://www.jini.org/wiki/Jini_Distributed_Leasing_Specification
The bottom line seems to me to be that the observed behavior may be
permitted, but is weird enough that I need to investigate it to find out
if it is an indication of a bug.
A single write call using the transaction protects it for at least half
an hour. That is just the longest time I've tested - it may protect it
indefinitely, which would be a bug. There are no leases involved longer
than one minute.
Patricia
