[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
Chris, I agree with everything you say. You can't possibly use persistDuration to control how long the conversationId has to be persisted. No argument at all. I am simply less trusting than you are of "reasonable implementers" so I suggested underlining that persistDuration is not applicable to message ordering and conversationId retention. That's all. If I really had my way, I would capture a number of the points from your posting in the non-normative statement that persistDuration is not applicable to meesage ordering and conversationId retention. 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 ************************************************************************************* Christopher Ferris <chris.ferris@sun.com> on 12/05/2001 10:17:12 AM To: ebxml-msg@lists.oasis-open.org cc: Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId Marty, I respectfully disagree. I don't think that we need to say anything. persistDuration is a parameter that the parties have agreed to use as the minimum amount of time that the party shall commit to preserving message artifacts necessary for support of the RM function (in many cases, messageId is sufficient so that possible duplicate transmissions of A MESSAGE can be detected). A conversation will potentially have a SIGNIFICANTLY longer duration than the lifetime of a single message for purposes of reliable delivery. It could be weeks or months. IMO it would be foolish to reuse the persistDuration for purposes of determining how long to preserve the conversational state of an exchange between parties which would include SequenceNumber when used in conjunction with message ordering. Conversational state MUST be preserved for the life of the conversation, period, full stop. One could include the list of messageIds of all messages for a conversation in the conversational state, but that would be potentially inefficient w/r/t persistent store, especially given that after persistDuration has expired the sending MSH should not (must not?) attempt to redeliver a message to the receiving party that has been unacknowledged. The point is that the purpose of the persistDuration parameter is to provide a reasonable limit on the amount of time that a receiving party needs to preserve messageId in persistent store for purposes of filtering out potential duplicate transmissions of a single message. It has NOTHING to do with the conversational state of an exchaneg between parties. Cheers, Chris Martin W Sachs wrote: > You need to say enough in the MSG spec to inform an implementer that > persistDuration follows different rules for conversationId and > last-ordered-message than for reliable messaging. Considering the amount > of discussion we have had on this point, we cannot assume that a > "reasonable implementer" will know what to do. There are plenty of examples > in the newspapers about deadly mistakes made by reasonable implementers. > The Risks Forum mut be full of them. > > 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 > ************************************************************************************* > > > > Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 09:39:42 PM > > To: David Fischer <david@drummondgroup.com> > cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb <dlw@exceloncorp.com>, > ebxml-msg@lists.oasis-open.org > Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId > > > > The thing I have trouble with here is why we have to say anything > in the spec. This is too suggestive of implementation detail > IMO (although probably accurate). Why do we need to say anything > about this at all? > > Cheers, > > Chris > > David Fischer wrote: > > >>OK, I think that will work, but it is not the whole message which needs >> > to be > >>saved. Once the message is delivered to the application, just the >> > MessageId, > >>CPAId, persistDuration, ConversationId, SequenceNumber (did I get >> > everything?) > >>need to be saved. The spec says now only the MessageId needs to be saved >> > but > >>that's not enough for MessageOrder. >> >>David. >> >>-----Original Message----- >>From: Martin W Sachs [mailto:mwsachs@us.ibm.com] >>Sent: Tuesday, December 04, 2001 5:01 PM >>To: Christopher Ferris >>Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org; >>ebxml-cppa@lists.oasis-open.org >>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >> >> >> >>Then it should only be necessary to add to the MSG spec words that say: >> >> The MSH shall preserve in persistent storage the last message in the >> conversation that was sent in order to the application until either a >> subseqent in-order message arrives or until the conversation ends >> (regardless of how long that takes). These words probably should be >> modified if preserving some header information is all that is needed. >> >> The MSH shall preserve in persistent storage the conversationId of an >> in-progress conversation until that conversation ends (no matter how >> long that takes). >> >> >>No change is needed to the CPPA spec unless it now does not say that >>persistDuration is the mininum length of time... (see Chris' words >> > 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 >> >> > ******************************************************************************** > > >>***** >> >> >> >>Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 05:46:11 PM >> >>To: Martin W Sachs/Watson/IBM@IBMUS >>cc: David Fischer <david@drummondgroup.com>, Dan Weinreb >> <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org >>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId >> >> >> >>right now, the spec suggests #1 which is that pd is the >>minimum length of time that a party will commit to >>preserving a message (or its relevant artifacts) in >>persistent store for purposes of filtering duplicate >>messages. >> >>Cheers, >> >>Chris >> >>Martin W Sachs wrote: >> >> >> >>>One of these possibilities: >>> >>>1. If the MSG spec states that persistDuration is a minimum length of >>> >>> >>time, >> >> >>>then all you need is to add words to the MSG spec conveying additional >>>rules when message ordering is in effect. >>> >>>2. If the MSG spec states that messages that live until persistDuration >>>MUST be discarded right away, then we probably need additional text in >>> >>> >>both >> >> >>>the MSG and the CPA spec. >>> >>>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 02:39:43 PM >>> >>>To: Martin W Sachs/Watson/IBM@IBMUS >>>cc: Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org >>>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> >>> >>> >>> >>> >>> >>> >>> >>> >>>---------------------------------------------------------------- >>>To subscribe or unsubscribe from this elist use the subscription >>>manager: <http://lists.oasis-open.org/ob/adm.pl> >>> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >>---------------------------------------------------------------- >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.oasis-open.org/ob/adm.pl> >> > > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > ---------------------------------------------------------------- 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