RE: RM Group Definitions

[Jim Hughes <jfh@fs.fujitsu.com>]

At 06:30 PM 8/30/2000 -0400, mwsachs@us.ibm.com wrote:
>One rejoinder in line.

>f) messages sent reliably  on a sender-transport-receiver triple should be
>received/processed in the same  sequence. Marty has expressed several times
>that this needed to be true for  RM-Groups, and if we eliminate grouping,
>the principle should apply to  singleton messages. This concept follows
>KISS and was in the original Fujitsu  proposal.
>
>Not so sure I agree on this one.  Given that multiple,  independent
>BP-level conversations may be occurring over the same
>sender-transport-receiver triple, requiring ordering at the
>sender-transport-receiver triple level could prevent valid messages from
>being  processed.  I can understand the need when RM-Groups were involved
>and  multiple transactions were being sent before receiving ACKs, but my
>concept of  KISS in the singleton message scenario would be for the sender
>to manage the  ordering (i.e., if ordering is required, the sender must
>wait for the ACK before  the next message is sent).
>
>MWS:  You are right that ordering need not be global.  However the order of
>the messages in a given conversation must be preserved.  This is a
>significant point if a conversation can include multiple messages which do
>not have business-level responses.

Does the Message Service Handler (MSH) need to be aware of the ordering of 
messages in a given conversation - or even be aware of any conversation 
'state' between messages? I was working under an assumption that the 
application kept this information, and 'ordering' meant that one reliable 
message on a sender-transport-receiver triple had to complete (either by 
ACK or timeout) before the next reliable message could be sent. (All this 
discussion assumes we no longer have the concept of RM grouping, of course).

This solution certainly opens up the possibility that a rogue application, 
setting an infinite timeout with a lost message, might cripple the link 
without some safeguards.

>(If the conversation is pure
>request-response, that will force the ordering.)  I am not convinced that
>with the current reliable message draft, merely requiring a transport-level
>ACK is sufficient to guarantee ordering.

Not sure of your comment. The current draft doesn't have anything to say 
about transport-level ACKs - it only deals with MSH-level ACKs and is 
"agnostic" to the actual transport used.

>  That will depend on how we
>specify the relationship between the transport-level ACK and the RM ACK.  I
>discussed this in an earlier posting.  Note that, as I discussed in
>previous postings, retry of missing messages can get the messages out of
>order.

Switching back to the current draft, which proposed RM-Groups, you are 
correct that within an RM-Group the actual ordering of messages can be 
indeterminate if there re-sends. We could work on that issue, but if there 
is general agreement to abandon the concept of groups for now, we don't 
have to have that discussion!  :-)

Jim