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: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo


As Chris pointed out, we need to carefully consider this.  So, I am sending this
out again (slightly modified -- retryCount goes in Via).  Does anyone see any
problems with this or does anyone have an alternative proposal?

Regards,

David Fischer
Drummond Group.
===============
Proposal:
A retryCount attribute on Via.  This parameter can only be set by the From Party
MSH and MUST start at zero.  The first retry, retryCount is set to one, etc.

Discussion:
Duplicate detection, as always, is detected by the To Party and From Party based
upon MessageId.  Duplicate detection by the Intermediary is based upon MessageId
plus retryCount.

For example (see attached flow chart):

Let's say there are three intermediaries (nodes B, C, D).  A is the From and E
is the To.  A sends a message with MessageId of 1 and retryCount of 0 (let's
call this ID 1.0).  We will assume two failures occur during send -- the message
makes it to D but has problems sending to E.  The Ack from C also fails going
back to B.  Since A did not get a DR within retryInterval, it decides* to retry
using ID 1.1.  B will not see this as a duplicate and will pass it on.  B will
also retry to C using ID 1.0.  C will see ID 1.0 as a duplicate so it will not
send on but C will send an Ack back to B (who gets it).  C will also receive ID
1.1 and send it on since it is not a duplicate.  Meanwhile D has finally made
the send to E and the DR and Ack have come back from E.  D then receives ID 1.1
from C and sends it on since it is not a duplicate.  E receives ID 1.1 but since
E is the end, it sees ID 1.0 and ID 1.1 as duplicates (it only uses MessageId).
E sends an Ack to D for ID 1.1.  E sees ID 1.1 as a duplicate so it does not
pass on to its application but it does send another DR back to A.  A finally
receives two DRs, one for ID 1.0 and another for ID 1.1.

*The retry on lack of DR may be either manual or automatic -- implementation
dependant.

RM9.jpg



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


Powered by eList eXpress LLC