Title: [wsrp-interfaces] Leasing use cases and proposal for 2.0
Do I
understand the grid leasing concept correctly? It's a hard expiry, not
related to the last time the handle was accessed, right? So that even if a
Consumer has been actively sending requests using a portlethandle that has a 3
month lease on it, when the lease is up the handle gets gc'ed, unless the
Consumer explicitly requests (and is granted) an extension for the
lease.
And
<alank>inline</alank>...
-----Original Message-----
From: Andre Kramer
[mailto:]
Sent: Friday, January 16, 2004
3:12 AM
To:
Subject:
[wsrp-interfaces] Leasing use cases and proposal for 2.0
State maintenance using a "leasing" concept:
[10] Cary G. Gray and David R. Cheriton.
Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache
Consistency. In Proceedings of the 12th ACM Symposium on Operating Systems
Principles, December 3-6, 1989, pages 202-210.
or lifetime management through timeout based
renewal mechanisms (explicit operations or implicit through use) is a very
common way to manage state in the presence of failures in distributed systems
(Java's Jini, Microsoft's .NET Remoting). In fact, we already use implicit
leases and "soft state" via WSRP 1.0 Session Handles and possibly (at the
implementation level) cookie-based Application Server http
Sessions.
However, consumer registrations and portlets
lifetimes are currently only scoped by explicit deletion (deregister and
destroyPortlets operations). This leads to resource reclamation problems in
several scenarios:
If a consumer goes down and never recovers, a
producer may be unable to reclaim registrations and portlet handles and
associated resources. And doing so would probably require administrator
intervention: consumer admin to report or confirm failure and producer admin
to manually delete all registrations held by a consumer (portlets may then be
garbage collected simply).
If a consumer represents a "virtual organization"
then WSRP handles may be forwarded to fairly autonomous consumer entities but
created centrally in the organizational domain (delegated administration) and
they may even be shared between several semi-independent entities at any one
time. Handle destruction then becomes a fairly difficult distributed garbage
collection problem.
Our clone on write mechanism could also easily lead
to handle leakage bugs or errors (say if a consumer crashes or does not get a
performBlockingInteraction response due to network failure). How does a
producer know that the consumer has received the reply from a "clonePortlet"
operation? Should it drop the handle if no getMarkup on the new handle after
some time? What if the consumer is staching away handles for later future
use?
<alank>clone
on write handles should be handled identically to handles that result from an
explicit call to clonePortlet, I
think.</alank>
Furthermore, significant confusion exists over the
requirements on what to do when a deregister() or destroyPortlets() operations
fails at the network level, even in WSRP 1.0. The consumer should re-try at a
later time but for how long? What if the producer is down for some length of
time and the consumer gives up before the producer comes back?
Producers could just unilaterally destroy handles
when not used for some extended period of time (and I suspect some 1.0 systems
will want to do this) but we have no standard way to advertise this fact, or
the nominal expiry period, through producer meta-data. That would be the
minimum useful addition we could make to address the above scenarios. A
consumer must then periodically make use of some operations to keep alive
handles.
However, rather than invent our own leasing
concept, an alternative approach would be to view WSRP registration and
portlet handles as OGSA (www.ggf.org) Grid Service handles (resolvable to grid
service instance references through which a standard (OGSI) "Grid Service
Interface" (SOAP/WSDL based) can be invoked). This interface features the
following operations:
requestTerminationAfter() - i.e. not before some
(possibly infinite) time period
requestTerminationBefore() - i.e. not after some (possibly infinite)
time period
The currently set terminationTime is available as
grid service data (similar to our WSRP properties).
see: http://www.ggf.org/ogsi-wg
https://forge.gridforum.org/projects/ogsi-wg/document/Final_OGSI_Specification_V1.0/en/1
A consumer and producer would have to agree that
our handles represent Grid Service Handles (GSHs) and handle values (the
strings) must be resolvable to Grid service references (a WSDL doc typically)
by some agreed mechanism (using a Grid "HandleResolver" which seems to be an
underspecified area of the current Grid specifications :-(.
A consumer can then resolve a WSRP handle (think of
this as casting the handle to a wsdl stub / proxy for a GridService portType)
and negotiate a leasing contract with a producer. Note that, handles need not
be backed by full grid service "objects" but can be emulated by a container,
so we add little cost and that the Grid specs allow the lifetime of one handle
to scope another (as would be the case for our portlet handle scoped by a
registration). We could make a portlet grid service reference its "parent"
producer grid service to ease discovery etc.
For further motivation (of lease based lifetime
management) from the Grid see: http://www.globus.org/research/papers/ogsa.pdf section
6.3.
regards,
Andre
PS OGSI could also be used for portlet properties /
metadata and (asynchronous) notifications.
