Re: [wsrm] Fwd: message ordering

[John Fuller <jfuller@wernervas.com>]

In my implementation at http://sourceforge.net/projects/easywsrm/
by default I implemented it the 3rd way, storing each message,
signaling the application layer when the "end" had been received
/and/ the (count-1) for the group matched the end number for the group.
Storing the messages themselves facilitated duplicate elimination
and message ordering policies.
Another advantage of using intermediary storage is that it should
be more scalable and less vulnerable to denial of service attacks
than a stateful in-memory implementation.


On Wednesday, September 10, 2003, at 04:29 PM, Jacques Durand wrote:

> inline:
>
> -----Original Message-----
> From: John Fuller [mailto:jfuller@wernervas.com]
> Sent: Tuesday, September 09, 2003 1:07 PM
> To: 'wsrm@lists.oasis-open.org'
> 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.
> >>
> >>