[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: persistDuration and retries
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC