Some comments below.
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
*************************************************************************************
David Fischer <david@drummondgroup.com> on 12/04/2001 11:16:21 AM
To: Dan Weinreb <dlw@exceloncorp.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Dan, did you mean to imply that messages are no longer stored once they are
acknowledged? This is not the case. Messages must be stored longer than
persistDuration. In your scenario, when 12 got to the Receiving MSH, 1-10
are
still in the store. If you wait so long that 1-10 have passed
persistDuration,
then I think you have waited so long that it does not matter any more.
I see your point about what happens if there is nothing in the store and
the
Receiving MSH gets a message with a number larger than 1. However, this
implies
the last ordered message/MessageId (which has been delivered in order) must
be
stored indefinitely (forever?) which is probably not acceptable.
MWS: For most conversations, there will be an indication of an end, at
which time
the last ordered message can be discarded. I guess if storage is tight,
you
only need to keep the sequence number and conversationId of the last
ordered message
This also
points out the conflict between Message Order and persistDuration. What if
messages 1,2,3,4 have persistDuration of 2 days. Messages 1,2,4 are
delivered.
The MSH hands 1,2 to the application but holds 4. For some reason, 3 is
not
delivered for 3 days. In this case 3,4 have already passed persistDuration
so
they are not delivered. The next day, 5 is delivered. Since 3,4 were not
delivered, then 5 cannot be delivered (nor any subsequent messages) even
though
it is still within TTL, and the ordering is forever broken for this
ConversationId. We may have to say Message Ordering does not work if any
message in the order fails to be delivered within its persistDuration (or
maybe
TTL)? Of course, all this can be adjusted at run time by increasing the
value
of persistDuration in the CPA. Once again, MessageOrdering is based on
persistDuration.
MWS: All of which says that some additional rules are needed on discarding
messages
in the presence of ordering. The last ordered message cannot be discarded
until
either the next message in the sequence arrives or the application ends the
conversation,
regardless of its persist duration. Similary, if there is a gap in the
sequence numbers,
all the out of sequence messages must be preserved, regardless of
persistDuration,
until they can be delivered. The MSG or CPPA specification must provide
advice on
how long to set persistDuration depending on what combination of reliable
messaging
and ordering is being used.
I am wondering why are we messing with all of this? Did I see Marty
suggest, if
messages are order dependant, just wait for acknowledgment from the end
before
sending the next message? Sounds good.
MWS: Ahhh... the light begins to dawn.
Regards,
David.