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

[Doug Bunting <Doug.Bunting@Sun.COM>]

Iwasa,

This sounds pretty good -- and thanks as well for your previous set of 
comments on the "about review of Section 2-2.5, 5.2" thread.

Unfortunately, the specification is not silent on whether the ordered group 
is immediately terminated.  Note that the combination of rules in Section 
5.1 as things stand means only the Receiving RMP would do immediate closure 
and deliver no further messages in the group for T5; the Sending RMP is 
supposed to continue its resend loop after it detects the closure condition 
when GuaranteedDelivery is enabled.  This is therefore an issue partially 
about making the Sending and Receiving RMP behave similarly.

Lines 1158-1163 say:
"
When a group is closed in the Receiving RMP, the RMP expects to receive no 
new message for this group. After a group is closed and before it is 
"removed" (see definition below), a Receiving RMP MUST NOT deliver messages 
received with this group identifier, whether or not they are duplicates of 
previous messages and regardless of whether they result from a resending of 
previously failed messages initiated before closing on the Sending RMP (in 
case GuaranteedDelivery is enabled).
"

Line 1311 says "The RMP MUST close the group."  And, so...

Of the 5 termination conditions, two (3 & 4) require completion before 
closure and two (1 & 2) are invoked based on conditions which apply equally 
to all messages in the group.  The current T5 is unique in its application 
of a single-message condition to the entire group.

My proposed amendment to the changes Iwasa pulled together should make T5 
more like T3 and T4.  It is (leaving everything else as Iwasa described):

In 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 faults with a fault code other than MessageProcessingFailure. 
If all previous messages for the group have been received, the group is 
closed immediately. Alternatively, the group is closed when the RMP 
receives the last missing message in the group."

[I prefer the "If ... Alternatively" form over the current mix of the 
primary and secondary tests in the first sentence of the "Receiver Side" in 
T3 and T4.  I suggest we use the form shown above there as well.]

- replace on "Sender side" part:
  "Triggering event: in an ordered group, a non-acknowledged message expires."
      with:
  "Triggering event: in an ordered group, an unacknowledged message expires 
or the RMP receives an RM Fault describing this Reliable Message with a 
fault code other than MessageProcessingFailure."

[Most of what I am doing on the "Sender Side" is editorial.]

In Section 5.1.3.6 (Summary of Group Termination Rules), the bottom 
leftmost cell of Table 26 and 27 should change from
  "When a group is ordered AND a non-[delivered|acknowledged] message has 
expired."
to
  "When a group is ordered AND an un[delivered|acknowledged] message 
expires or faults."

I believe the bottom rightmost cell of Table 27 is incorrect and should 
(since we know GuaranteedDelivery is enabled) change from
  "(after closing) Remove the group immediately."
to
  "(after closing) Remove the group after all messages have been either 
acknowledged or faulted."

thanx,
	doug

On 05-Aug-04 03:29, iwasa wrote:

> I think we can simply resolve CF4 issue with
> Jacques proposal with Doug's amendment,
> with status quo for the case Doug raised recently.
> (And I like to make amendment for the proposal above
>  as described in the last portion of this e-mail.)
> 
> Since the spec is silent for the Doug's case currently,
> it is implementation matter how to treat this case.
> And it doesn't brake interoperability even if
> the group is terminated right away or not, because
> the Sending RMP can know what messages
> are delivered anyway. So it is no big issue
> whether the group can be terminated right away
> or not. I like this was left as implementation
> choice, and the spec is silent.
> 
> The Jacques's proposal with Doug's amendment
> I mentioned earlier in this mail 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
>   other than 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 other than 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."
> 
> -------------------------------------------------------
> 
> And I like to propose amendment for the first resolution
> as follows:
> 
>  "A Sending RMP MUST 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."
> 
> Because I believe "SHALL NOT" is equivalent with
> "MUST NOT", and latter is better to avoid any confusion.
> 
> Thanks,
> 
> Iwasa
> 
> ----- Original Message ----- 
> From: "Doug Bunting" <Doug.Bunting@Sun.COM>
> To: "Jacques Durand" <JDurand@us.fujitsu.com>
> Cc: "WSRM (E-mail)" <wsrm@lists.oasis-open.org>
> Sent: Thursday, August 05, 2004 3:33 PM
> 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
>>> >
>>>
>>To unsubscribe from this mailing list (and be removed from the roster of
> 
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
> 
>