Re: [ws-rx] i0019 - a formal proposal

[Doug Davis <dug@us.ibm.com>]

Yet more comments  :-)
-Doug


Christopher B Ferris/Waltham/IBM@IBMUS wrote on 08/25/2005
09:42:27 AM:

...
> > > > After line 378, add to the description of the SeqAck
elements:
> > > >   /wsrm:SequenceAcknowledgement/wsrm:Final
> > > >   This optional element, if present, indicates
that the RM
> > > >   Destination is not accepting new messages for
the
> > > 
> > > We would probably want to say more than 'new messages'.
Something 
> along 
> > > the lines of '... indicates that the RM Destination will
not deliver 
> any 
> > > message that is not listed in the acknowledgement, to the
Application 
> > > Destination.
> 
> Seems to me that we need to make it abundantly clear that once an
RMD
> has issued such a SeqAck, any received message with a <Sequence>
element 
> belonging to the Sequence identified by the SeqAck MUST be silently
> ignored by the RMS. We do need to permit AckRequested as well as Close()
> and Terminate() messages for the Sequence though... it is only those
> messages
> that carry a Sequence header that are affected.

The latest version of the proposal (sending soon)
does make it clear
that RM protocol messages can still be processed,
but not app messages.
As for ignoring dups - I'm not sure - what if the
DA is AtLeastOnce, that
would seem to imply dups can be accepted and processed,
no?  Uh oh, did
I just enter the entire AtMostOnce mode discussion??
 noooooooo!    :-)

...
> > > > To the end of that para, at the end of line 574, add:
> > > >   Note, under normal usage the RM source will
complete it use of
> > > >   the sequence when all of the messages in the
Sequence have been
> > > >   acknowledged.  However, the RM Source is
free to Terminate
> > > >   a Sequence at any time regardless of the acknowledgement
state
> > > >   of the messages.
> > > > 
> 
> s/will complete it use of/will complete its use of/

Done

...
> > This text is for the case where you sent
5 messages but message 3 is
> > lost.  If a Close() is sent I don't believe that messages
4 and 5 should
> > be delivered to the Dest.App. since message 3 was never recieved.
 In 
> > this case the only think that makes sense to me is to generate
a fault
> > for message 4 and 5 just as if they had arrived late to the RMD
- 
> meaning
> > a SequenceClosed fault.
> 
> I guess I'm with Anish... I don't see why this is necessary. I think
that
> we should make it clear that as per the InOrder DA requirement, since
> there
> is a gap below, that the messages MUST NOT be delivered for processing
by 
> the
> AD.
> 
> Consider that the SeqAck has already acknowledged that the messages
had
> been received, seems to me that subsequently receiving a fault on
the 
> ack'ed
> messages might confuse the RMS.

I'm torn but slowly being convinced that perhaps it
shouldn't fault for
those.  I agree it does seem inconsistent to
Ack them and then Fault them,
but at the same time I thought giving some indication
back to the RMS's
app that those messages were not processed would be
nice.  Perhaps the RMS
should generate the Fault instead of the RMD??