Title: RE: [wsrm] Fwd: message ordering
inline:
-----Original Message-----
From: John Fuller [mailto:]
Sent: Tuesday, September 09, 2003 1:07 PM
To: ''
Subject: [wsrm] Fwd: message ordering
>
An even stricter requirement than definition 2 would be to only pass
the whole group on
after all messages have been received for the group: the group would
be all or nothing,
like a transaction, and the RMP would be responsible.
Admittedly, by definition 2, the application layer could just go off
the "end" event since messages are ordered, but a stricter requirement
would hide the coordination all-together from the application layer....
<Jacques> this "all or nothing" option is different from definition (2)
as a missing message would not just terminate the consecutive sequence
as far as the receiving app is concerned, but would cancel all of it.
It is indeed a "transactional" 3rd option that has obviously its own challenges:
Has the RMP enough space to persist the entire sequence? if not, its app will never
get these... deadlocks may occur across sequences. Also sequences have to be
clearly ended.
> On Monday, September 8, 2003, at 11:15 PM, 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=20
>> "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)=20
>> that address different ordering requirts. Roughly:
>>
>> -=A0=A0=A0=A0=A0=A0 "message ordering" (o1): loosing some messages =
> will not=20
>> "break" a sequence, provided that what is passed to the receiver=20
>> application is still ordered. We can imagine that a flow of
>> messages=20=
>
>> from a monitoring device could just need that.
>>
>> -=A0=A0=A0=A0=A0=A0 "consecutive message ordering" (o2) a missing =
> message is not=20
>> allowed in the delivered sequence. A message that cannot be waited
>> for=20=
>
>> any longer, should break the sequence, and subsequent messages not
>> be=20=
>
>> passed to the app (so this enforces passing only consecutively
>> ordered=20=
>
>> sequences).
>>
>> The spec seems to endorse either o1 (section 2.4) or o2 (section=20
>> 3.3.2). Instead, it should clearly define these two variants.
>>
>> Definition 1: (message ordering, o1 above):
>> When "message ordering" is required, an=A0 RMP implementation that
>> is=20=
>
>> required to do "message ordering" , MUST NOT make any two received=20
>> messages available to the application in a different order than
>> their=20=
>
>> sending order.
>>
>> Definition 2: (consecutive message ordering, o2 above):
>> When "consecutive message ordering" is required, an RMP
>> implementation=20=
>
>> MUST enforce "message ordering", and in addition MUST NOT make a=20
>> received message available to the application if its was sent after=20
>> another message that is not yet available to the application.
>>
>>
