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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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

Subject: RE: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption ofdeliverability


Your point on the distinction between what may be delivered vs what will be delivered is understood, but I think that if the RMD knows that a previously acked message that cannot be delivered due to the existence of in-order delivery and a gap, might be a situation best confessed.

Your second comment concerning the withdrawal of a previously acked message in SeqAck/Final is exactly what I am prosing making legal in the protocol.  I think that it is not a protocol violation, per-se, since the sequence is closing, and that the RMD will accept no further messages for the sequence.  That closure does not imply that the RMS is expected to re-send messages that are missing in the acknowledged sequence since the sequence is effectively dead.  SeqAck/Final does not change the future order or existence of either messages or control messages, it is just informative.

In the absence of ordered delivery, SeqAck/Final always reflects messages that might be delivered, but it does not with my interpretation of the likely implementations of ordered delivery. My proposal rests on this assertion.


On your last point, I agree that the text might be tightened, for all SeqAcks other than SeqAck/Final which my proposal provides the freedom to do exactly that in the spirit of truthful ending status.





From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, March 23, 2006 6:31 AM
To: Bob Freund-Hitachi
Cc: [WS-RX]
Subject: Re: [ws-rx] New Issue; SequenceAcknowledgement:Final assumption of deliverability



Taking responsibility for delivery and delivering are two separate things.
Just because a message *could* be delivered, doesn't mean that it ever *can* be delivered.

Are we saying that SeqAck/Final should not ack messages that it knows cannot be
delivered? What if the message had been previously ack'ed? Then, introducing a
GAP where previously there had been an acknowledged message would be in violation
of the protocol (at least as I understand it).

I would also point out that apparently, while there is guidance related to Nack-ing a message
previously Ack'ed, there is no guidance that prohibits sending a SeqAck that introduces
a gap that had previously been Ack'ed. I think that this needs to be rectified.

I will gladly introduce a separate issue if people think that it deserves to be addressed
on its own merits.


Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com> wrote on 03/22/2006 02:07:29 PM:

> Description
> Modify definition of SequenceAcknowledgement:Final to reflect
> accurate ending delivery capability status.

> Justification
> The protocol defines the SequenceAcknowledgement:Final element which
> contains the final summary of message acknowledgements at the
> closure of a sequence. It is assumed that the RMD has taken
> responsibility for all messages that have been acknowledged.  
> Depending upon the operation of the RMD and its interface with the
> application, Messages that have been previously acknowledged as
> received by the RMD, may never be deliverable.  One such case of
> note that comes to mind is the situation of a message sequence that
> is being delivered in-order to an application which is closed at the
> time when one or more gaps that may exist in the sequence.  If this
> situation occurs, the RMS will have incorrect information concerning
> exactly which messages have been or will be deliverable at the
> conclusion of a sequence.

> Note that there is nothing in the spec that states what the RMS is
> to do with the information contained in SequenceAcknowledgement:
> Final.  This proposal does not add any such statement, but it does
> permit the information to be potentially interpretable.

> Target: core
> Proposal:
> Reference Core Spec CD03
> insert after line 613:
> SequenceAcknowledgemnt:Final shall identify only those messages that
> have been delivered or which the RMD has taken responsibility for
> delivery without regard to the previous acknowledgement status of any message.

> State Table impact: None

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