[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Yes Marty, absolutely. I think there are potential problems (discussed below) which make MessageOrder quite fragile. I am shuddering over the thought of changing the persistDuration rules depending upon whether or not MessageOrder is present (wouldn't this constitute a CPA override!). I still like your other solution. Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, December 04, 2001 10:50 AM To: David Fischer Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId 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. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Monday, December 03, 2001 9:40 PM To: david@drummondgroup.com Cc: rberwanger@btrade.com; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId Date: Mon, 03 Dec 2001 20:30:08 -0600 From: David Fischer <david@drummondgroup.com> If there are no messages in the persistent store pertaining to a conversation, then there is no need to store it any longer for the purposes of maintaining message order. I'm not sure that would work. Suppose two parties establish a conversation with ID 5551212. Party A sends messages numbered 1 through 10 to Party B, and party B's application reads all the messages and acknowledges them, so that there aren't any messages still waiting to be delivered to B. Now a message arrives at B with conversation ID 5551212 and a sequence number of 12. The MSH at B's end has to realize that is should not deliver this message to the application because message 11 hasn't arrived yet. So the MSH at B's end has to be storing somewhere the fact that the most recent message delivered to the application from conversation 5551212 is 10. -- Dan ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC