[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
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC