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


Yes, you are correct -- terminology difference.  Only the MessageId (and
associated fields like TimeStamp, persistDuration and maybe ConversationId. . .)
have to be stored.

David.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Tuesday, December 04, 2001 1:04 PM
To: david@drummondgroup.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId


   Date: Tue, 04 Dec 2001 10:16:21 -0600
   From: David Fischer <david@drummondgroup.com>

   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.

I've heard this said before but I don't understand it.  Why must
messages be stored longer than persistDuration?

In fact, once a message has been given to the application, why does it
have to be stored persistently beyond that point?

And if it does have to be stored beyond that point, for how long does
it have to be stored?

You *do* have to store the MessageId of the message if you're doing
duplicate elimination, but that doesn't require storing the message
itself.

			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.

Why is that so long that it doesn't matter any more?  Perhaps MSH A
sends 10 messages, and MSH B receives and acknowledges them, and MSH B
delivers all ten messages to its application.  Then three weeks pass
(the receiver is a supplier of rabbit soup, and it takes three weeks
to catch the rabbit), and then (perhaps after the B sends something to
A), A sends message 11 and message 12, and message 12 arrives first.
B needs to know that 12 is out of order, even though a lot of time
has passed.

							      However, this implies
   the last ordered message/MessageId (which has been delivered in order) must
be
   stored indefinitely (forever?) which is probably not acceptable.

No, just until the conversation is over.  (It's just like TCP.)

								     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.

Well, if you asked for reliable messaging and you asked for messages
to be delivered in order, then surely you don't want to see message 5
when you haven't seen message 3.  (I think we agreed that if you ask
for messages in order, then you have to be using reliable messaging,
which means acks are requested and duplicates are eliminated.)

I think the real problem here is: what has become of message 3?  The
sender ought to realize that an ack has not come, and so it should
retransmit message 3.  But if it just can't get message 3 through, on
a conversation on which message ordering has been specified, then
indeed no subsequent messages can be transmitted.  The conversation
is stuck until message 3 gets through.

   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.

Well, I don't think it sounds good, for reasons that I have already
explained at length.

-- Dan



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


Powered by eList eXpress LLC