OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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...

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.

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
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]