Chris,
There must be an internal timeout within the message service by which it
decides when to retry. I'm not arguing that there is a need to put it in
the CPA.
"Initial timeout" is in the equations in an attempt to put all the
combinations on equal footing. It is simply the timeout for the first
retry. However, I may have been confused late at night. If RetryInterval
applies to the minimum time to the first retry as well as to subsequent
retries, and if I attempt to make the equations easier to parse, I get for
the possible times at which a delivery failure will be declared:
> persistDuration
> RetriesxRetryInterval+timeout_of_last_retry
if RetryInterval is longer than the timeout
> (Retries+1)xTimeout
if the timeout is longer than RetryInterval.
In any case, there are three different times at which a delivery failure
may be declared, depending on which is shorter. If PersistDuration is the
shortest, and it expires, a delivery failure will be declared although the
number of retries is not exhausted, and the last retry will be cut off
without waiting for the full length of the acknowledgment timeout. It may
not matter much if Retries, RetryInterval, and persistDuration are
sufficiently large or long. It does appear to me that Retries and
RetryInterval are all that is needed; persistDuration is not needed and is
complicating things though it is probably not worthwhile to remove it at
this late date. That's why I suggested some non-normative discussion in
the CPP-CPA spec.
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
*************************************************************************************
christopher ferris <chris.ferris@east.sun.com> on 07/26/2001 07:45:04 AM
To: 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,
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