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


Your definition oif persistDuration is not quite correct. It should be
(quoting from section 10.2.8)

>>>The persistDuration value is the minimum length of time, expressed as a
[XMLSchema] timeDuration, that data from a reliably sent Message, is kept in
Persistent Storage by a Receiving MSH.<<<


-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, July 26, 2001 4:45 AM
To: Martin W Sachs
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
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
> 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

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

Powered by eList eXpress LLC