Re: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[christopher ferris <chris.ferris@Sun.COM>]

David Fischer wrote:
> 
> 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.

How does this work if the sending MSH knows nothing of intermediaries?
Are you suggesting that the Via element is now REQUIRED on all messages?

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

How does an intermediary distinguish itself as such? This seems to preclude
an MSH "module" that can be used anywhere as there is now a distinction between
how an intermediary MSH node treats idempotency checking versus how an endpoint
does so.

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

retryInterval applies to the RM retry. You are now stating that the DR is the RM
artifact, not the Acknowledgment. What happens when no DR is requested/required?
Does the sending MSH wait for the response message?

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

So now A has to wait for the total possible number of DRs from E before it can
stop worrying about the message. Why is A allowed to retry before it has
any indication that there is a problem? The same retryInterval as might be
used between A and B doesn't seem realistic to be reused between A and E
as there may be a wide discrepancy between the expected response from B
and the expected response from E. E may be only intermittently connected
for any variety of reasons.

Thus, a separate parameter is needed to specify how long to wait for
a DR (which is still optional as far as I'm concerned) or possibly the 
expected business response. As I understand, these are attributes that
are presently expressed in the BPSS (timeToAcknowledgeReceipt 
and timeToPerform).

> 
> *The retry on lack of DR may be either manual or automatic -- implementation
> dependant.
> 
>   ----------------------------------------------------------------------------------------------------
>               Name: RM9.jpg
>    RM9.jpg    Type: JPEG Image (image/jpeg)
>           Encoding: BASE64