RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId

[David Fischer <david@drummondgroup.com>]

Yes, Chris is right.

David.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Tuesday, December 04, 2001 4:46 PM
To: Martin W Sachs
Cc: David Fischer; Dan Weinreb; 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>
>