OASIS ebXML Messaging Services TC

 View Only

persistDuration and retries

  • 1.  persistDuration and retries

    Posted 07-26-2001 01:24
    The following point surfaced during today's CPPA F2F.
    
    Reliable messaging includes the following elements among others:
    persistDuration, Retries, RetryInterval.
    
       persistDuration defines the maximum time to allow for successfully
       retrying the sending of a message in the reliable messaging protocol.
    
       Retries defines the maximum number of retries that may be made for
       failure to receive a RM ACK.
    
       RetryInterval defines the time to wait before making a retry.
    
    A delivery failure is recognized if either persistDuration expires or the
    allowed number of retries has been used up.
    
    There is a bit of overdetermination going on here.  There are three
    different maximum times:
    
       persistDuration
       Initial timeout + (Retries-1)XRetryInterval+timeout_of_last_retry if
       RetryInterval is longer than the timeout
       Initial timeout + RetriesXTimeout if the timeout is longer than
       RetryInterval.
    
    Note that the value of the timeout is not defined in either the message
    service spec or the CPP-CPA spec.  It appears to be an implementation
    detail of the message service handler.
    
    In the message service specification, nothing appears to be said about the
    relationships among these times.  It appears that a delivery failure is
    recognized when the first of these maximum times expires. Note that if
    persistDuration expires first, the message service handler will recognize a
    delivery failure although the timeout following the most recent retry may
    not have expired.
    
    The CPP-CPA specification is also silent on this overdetermination.
    Because timeout is not defined, the CPA tools cannot check consistency.
    It may be worthwhile to put a non-normative discussion of this in the
    CPP-CPA specification.
    
    We should be concerned about persistDuration potentially causing the
    timeout for the most recent retry to be truncated, however.
    
    Regards,
    Marty
    *************************************************************************************
    
    Martin W. Sachs
    IBM T. J. Watson Research Center
    P. O. B. 704
    Yorktown Hts, NY 10598
    914-784-7287;  IBM tie line 863-7287
    Notes address:  Martin W Sachs/Watson/IBM
    Internet address:  mwsachs @ us.ibm.com
    *************************************************************************************