OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: persistDuration and retries


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



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


Powered by eList eXpress LLC