Re: persistDuration and retries

[christopher ferris <chris.ferris@east.sun.com>]

Marty,

The TRP team explicitly chose to remove the initial timeout
value. We felt that it was redundant with retry interval.

I don't understand why some ficticious InitialTimeout
is being added into the equations.

Cheers,

Chris

Martin W Sachs wrote:
> 
> 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
> *************************************************************************************
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard