RE: [wsrp-interfaces] Leasing use cases and proposal for 2.0

Title: [wsrp-interfaces] Leasing use cases and proposal for 2.0

Use of 
a handle may refresh a lease. And in practice, it is likely to do so. The 
main difference seems to be that clients can influence when a grid 
service instance should be considered for garbage collection, rather than just 
the time until which it should not. No strong guarantees are normally given but 
a time-sensitive grid service (e.g. an evaluation license that is supposed to 
run out in 80 days) may enforce the termination time (and not 
auto-renew).

 

I 
agree that both forms of cloning are subject to the same message loss problem 
but in some sense explicit clone (clonePortlet operation) is simpler, as 
the consumer knows that a copy is being attempted (e.g. it could log all lost 
responses for admin report back to a producer).

 

regards,

Andre

  
-----Original Message-----
From: Kropp, Alan 
  [mailto:]
Sent: 17 January 2004 
  00:18
To: Andre Kramer; 
  
Subject: RE: [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.