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



David,

I agree with what you are quoting but there is another place which states
that when persistDuration expires, a delivery failure is to be declared.
My point was that because of the way Retries and RetryInterval are defined,
persistDuration may run out before all the permitted retries have been
completed, potentially leading to a delivery failure that might be
replacing a later successful retry.

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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 07/26/2001 12:12:38 PM

To:   "'christopher ferris'" <chris.ferris@east.sun.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   ebxml-cppa@lists.oasis-open.org, ebxml-msg@lists.oasis-open.org
Subject:  RE: persistDuration and retries



Marty

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.<<<

David

-----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


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





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


Powered by eList eXpress LLC