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 begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:
chris.ferris@east.sun.com title:Sr. Staff Engineer fn:Christopher Ferris end:vcard