OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: persistDuration and retries


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.



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
org:Sun Microsystems, Inc;XTC Advanced Development
title:Sr. Staff Engineer
fn:Christopher Ferris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC