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


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]