Re: [wsrm] CF4 detailed proposal for V1.07

["iwasa" <kiwasa@jp.fujitsu.com>]

It looks like the proposal from Doug is good to me.

I don't believe there is any problem either of the
following resolution:
    1) immediate termination of the group, or
    2) terminate the group after previous
        valid/non-expired messages have been received/faulted.

There are different benefit for each of them:
    1) Easy to implement
    2) Increasing a chance of message delivery

So I am OK with either case, and Doug's proposed text
is OK to me.

If I raise one use case to support 2), it would be travel
agency use case. Air ticket reservation from a travel agency
must be processed in order, so a series of reservation
requests will be sent in a same group with guaranteed
message ordering.
In that case, even if the one of the middle of the request
expires, previous requests are expected to be processed
if it is possible. However the following messages of the
expired message must not be processed, since it brakes
the ordering.

Thanks,

Iwasa

----- Original Message ----- 
From: "Jacques Durand" <JDurand@us.fujitsu.com>
To: "'Doug Bunting'" <Doug.Bunting@sun.com>; "Jacques Durand"
<JDurand@us.fujitsu.com>
Cc: "WSRM (E-mail)" <wsrm@lists.oasis-open.org>
Sent: Friday, August 06, 2004 6:32 AM
Subject: RE: [wsrm] CF4 detailed proposal for V1.07


> Doug:
> I have no strong opinion either way - I'd go with what the TC decides.
> Just can't convince myself that it deserve much of our sweat at this
time...
> I think we may need a use case to appreciate the value of
> delivering as many messages as possible for a group that we know is
broken.
> (since with our "strong" definition of ordering, we decided anyway to stop
> deliver any
> message beyond the faulty/expired one)
>
> Jacques
>
> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@sun.com]
> Sent: Wednesday, August 04, 2004 11:34 PM
> To: Jacques Durand
> Cc: WSRM (E-mail)
> Subject: Re: [wsrm] CF4 detailed proposal for V1.07
>
>
> Jacques,
>
> We have different perspectives on this issue and I would much appreciate
> hearing from others.  I am certainly hoping for validation but mainly want
> a shared (TC) decision on whether an ordered group should terminate as
soon
> as any message (in or out of order) faults or expires.
>
> More on my perspective:
>
> My concern is not really about expired[1] messages that fall after a 1
> message gap though that was my example.  The issue is more about long gaps
> which might be filling in without problem until the oddball expires.  That
> expiration event is seemingly unrelated to the status of the messages
> successfully flowing from Sending to Receiving RMP.  I agree the "group is
> doomed"[2] but does that mean every in flight[3] message in the group must
> immediately go up in flames?
>
> Bursts of traffic due to RMP recovery will easily result in large gaps of
> message order seen at the Receiving RMP.  My preference is to deliver "as
> many messages as possible" in this situation, not based on requirements
> from that old document of ours but on predictability and a need to limit
> the magnitude of failure.
>
> Perhaps I am overly focused on the non-deterministic nature of this
> situation.  Perhaps I am thinking about an illegitimate optimization of
our
> protocol.  I am not convinced either is the case.
>
> thanx,
> doug
>
> [1] shorthand for "expires or faults", "expire or fault", "expired or
> faulted", ...
> [2] because every message after the one that expired will never be
delivered
> [3] not yet delivered and earlier in the sequence
>
> On 04-Aug-04 22:26, Jacques Durand wrote:
>
> > Doug:
> >
> > -----Original Message-----
> > From: Doug Bunting [mailto:Doug.Bunting@sun.com]
> > Sent: Tuesday, August 03, 2004 8:28 PM
> > To: Jacques Durand
> > Cc: WSRM (E-mail)
> > Subject: Re: [wsrm] CF4 detailed proposal for V1.07
> >
> >
> > Jacques,
> >
> > Modulo a touch of word smithing such as "different from" becoming "other
> > than", this looks pretty good.  I agree that, under our specification's
> > assumption that messages arrive intact, we have only one fault that
should
> > be considered transient.  I can incorporate this change without
additional
> > input.
> >
> > Except... I do wonder (now that you reminded me of Section 5.1.3.5)
about
> > closing an entire group when otherwise only messages after the one in
> > question would automatically fail.
> >
> > For example,
> > - I have message 2 sitting waiting for message 1 in an ordered group.
> > - Message 2 expires while I am waiting.
> > - At this point, should I reject message 1 even if it has not expired?
It
> > is without question the case that messages 2, 3 and higher will never be
> > delivered but...
> >
> > <JD> well, even if technically you could deliver msge 1 "in order" with
> > all previous ones, msg 1 arrives after that 2 expired, so the group
> > itself is doomed before
> >
> > you do so..., and its is expected that the group be terminated as soon
> > as it fails
> > (we do not have requirements to deliver "as many messages as possible"
> > that are in order,
> > in a failed group !) SO I would not bother...
> >
> >
> > Similar things could occur if an out of order (later) message arrives
that
> > encounters a permanent failure.
> >
> > Should these cases become a bit more specific, allowing lower numbered
> > messages to arrive and be processed as normal and aborting the group
> > (closing it or whatever the correct words are) as soon as no gaps remain
> > prior to the problematic one?  At worst (the Sending RMP does not try to
> > fill unacknowledged holes in the sequence), this would mean the group
does
> > not close until one of the other termination conditions occurs.
> >
> > <JD> again, i see this as an optimization - and even maybe not a
> > legitimate one:
> > one could argue that as soon as one of its message has expired before
> > being delivered,
> > an ordered group is broken and should be terminated right away and no
> > message be delivered
> > from this time on (even if in order with previous ones). That's a gray
> > area in our spec, but this interpretation is as good
> >
> > as yours... so I would just leave it as is for now.
> >
> >
> >
> >
> >
> > thanx,
> >         doug
> >
> > On 03-Aug-04 20:04, Jacques Durand wrote:
> >  > --------- CF4 on V1.07:
> >  >
> >  > Important note:
> >  > The three faults codes for which we recommend to terminate resending
in
> >  > 3.2.1,
> >  > are kind of arbitrary:
> >  > there is no chance that resending the exact faulted message will
change
> >  > its status from fault to succeed, no matter what the fault is, except
> >  > for the fault: MessageProcessingFailure
> >  >
> >  > In consequence, and in the light of latest discussions on CF4, my
> >  > proposal is:
> >  >
> >  > --------------------------
> >  > L580:
> >  > Replace:
> >  >  "A Sending RMP SHOULD NOT resend a message for which an RM-Reply
with
> >  > one of the
> >  >  following Fault types has been received and MUST notify its Producer
> of
> >  > a delivery failure instead: <bullet list>"
> >  > with:
> >  > "A Sending RMP SHALL NOT resend a message for which an RM-Reply with
a
> >  > Fault type other than
> >  > MessageProcessingFailure has been received, and MUST notify its
> Producer
> >  > of a delivery failure instead."
> >  > (note that the bullet list disappears).
> >  >
> >  >
> >  > -------------------------------------------------------
> >  > Section 5.1.3.5 (termination by ordering failure), the Triggering
event
> >  > line (in both Sender and Receiver)
> >  > should be modified as:
> >  >
> >  > replace on "Receiver side" part:
> >  > "Triggering event: in an ordered group, a received message expires
> >  > before delivery."
> >  > with:
> >  > "Triggering event: in an ordered group, a received message expires
> >  > before delivery, or a received message is faulted with a fault code
> >  > different from MessageProcessingFailure ."
> >  >
> >  >  replace on "Sender side" part:
> >  > "Triggering event: in an ordered group, a non-acknowledged message
> >  > expires."
> >  > with:
> >  > "Triggering event: in an ordered group, a non-acknowledged message
> >  > expires, or a sent message is faulted
> >  > with a fault code different from MessageProcessingFailure ."
> >  >
> >  > -------------------------------------------------------
> >  > Section 3.2.3 (Ordered Message Delivery), after L632 (at the end of
> >  > section) add:
> >  >  "A Sending RMP and a Receiver will terminate the group as specified
in
> >  > 5.1.3.5 (Termination by Ordering Failure)
> >  > when respectively receiving and publishing Faults other than
> >  > MessageProcessingFailure."
> >  >
> >  > (note that the normative requirement for this (MUST) is in 5.1.3.5)
> >  >
> >  >
> >  > Jacques
> >  >
> >
>