Re: [wsrm] about ordering

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 Jacques,

Jacques Durand wrote:

 Sunil,the decision "delayed vs lost" you point at is indeed essential to (o1), although the reason I would drop (o1) definition and keep (o2) - if we have to settle on only one -is more due to the logic of Ack + ordering (all messages are expected to be received + ordered )Note however that (o2) will also face the decision "delayed vs lost"  !

Yes, it does. But the difference is that in the (o2) case it's inefficiency issue,
where as in the (o1) case it's a compliance issue.

In the (o2), as you correctly pointed out, we keep pilling up the messages
which is inefficient but still legal & compliant. Which is not the case with
with (o1).

We need to have a global default for msg. expire time-out to be more
efficient in the (o2) case.
 

-Sunil
 
 
 
 
 
 
 
 
 
 
 
 
 - message #2 is "late", we have passed #1 to the app, and keep piling up  #3, 4,5... - when do we decide that it is not worth waiting anymore for #2? Even with "guaranteed delivery"a particular message may never go through (e.g. too big...).- from then the main difference with (o1) is that we won't pass anything more from this sequence to the app (3,4,5 are lost)while in (o1) we would pass them in the right order. Some decision criterion still needs be supported... even though more unlikely to be used, thanks to resending.Jacques

-----Original Message-----
From: Sunil Kunisetty [mailto:Sunil.Kunisetty@oracle.com]
Sent: Friday, September 12, 2003 11:15 AM
To: Jacques Durand
Cc: 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] about ordering
 

 Jacques,

 How does a Receiver distinguish a 'lost' message to a 'delayed' message? In other
 words, how does a Receiver assume that the message is 'lost' and not 'delayed'?

 Sender may have sent msgs. 1,2, & 3 in that order.  Msg. 2 was 'delayed' and
 somehow 3 shows up much before 2. Receiver may have assumed that 2 was
 'lost' and could have delivered 3 to the application. And then 2 arrives and
 assuming that it doesn't expire, what does the Receiver do with then?

 Since we don't have a global default for msg. expire time as of now and there
 is no explicit msg. lost header/token (from Sender to receiver), we can't easily
 distinguish a lost message to a delayed message. Because of this it will be very
 difficult to implement the "message ordering" (o1).

 Thanks,
 -Sunil

Jacques Durand wrote:

 

I propose the following (partial) answer for Rel 57, see below,
and also after this, see my concern on the way we seem to tie the "ordering" vs "no ordering" decision
to the seq number value (section 9.5 in the meeting minutes)

Regards,

jacques

Rel 57:

Proposal: Message ordering has actually two variants (o1) and (o2) that address different ordering requirts. Roughly:

-       "message ordering" (o1): loosing some messages will not "break" a sequence, provided that what is passed to the receiver application is still ordered. We can imagine that a flow of messages from a monitoring device could just need that.

-       "consecutive message ordering" (o2) a missing message is not allowed in the delivered sequence. A message that cannot be waited for any longer, should break the sequence, and subsequent messages not be passed to the app (so this enforces passing only consecutively ordered sequences).

The spec seems to endorse either o1 (section 2.4) or o2 (section 3.3.2). Instead, it should clearly define these two variants.

Definition 1: (message ordering, o1 above):
When "message ordering" is required, an  RMP implementation that is required to do "message ordering" , MUST NOT make any two received messages available to the application in a different order than their sending order.

Definition 2: (consecutive message ordering, o2 above):
When "consecutive message ordering" is required, an RMP implementation MUST enforce "message ordering", and in addition MUST NOT make a received message available to the application if its was sent after another message that is not yet available to the application.

Depending on which variant is used, o1 or o2, either one or the other of the current options (b)and (a) respectively
 in Rel 57 will apply.
The decision when to decide to "not wait anymore", remains to be decided (TimeToLive of the first unordered message? The min of TimeToLives of all unordered messages? Or a max unordered window size parameter, related to Rel 56.)

-------------------------------- meeting minutes 9.5:

"...The text is currently unclear on whether sequenceNO other than 0 can be used without ordering. The general consensus is no."

Issue: restricting the use of sequence numbers to the message ordering feature alone - and enforcing one message
per groupId otherwise, with seq nbr equal to 0 - will preclude implementations from using of a whole set of fast and space-efficient algorithms for duplicate elimination.

Proposal: Do not preclude using sequence numbers for other purpose than message ordering, at least until some conclusive results have been obtained on testing duplicate elimination algorithms. The spec should only require

that (groupId + seq.nbr) be always unique.
If the concern is about how to instruct an RMP what to do when it sees a sequence number in a message (should order? Should not?), that is another problem that could be solved separately.

If we resort to such tricks as using a different groupId for each message that does not require ordering, this amounts to enforcing duplicate check algorithms that are based on unique messageId strings. This will lead to more costly duplicate check (less scalable and less performant) and to the use of two different algorithms, if we still want to use sequence number-based duplicate check for ordered sequence that also need exactly once delivery.