OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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


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.  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.

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.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC