RE: [ws-rx] i0019 - a proposal: (more complete)

[Christopher B Ferris <chrisfer@us.ibm.com>]

I've interspersed some comments thoughout this post (including the 
included emails)

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/16/2005 07:50:07 PM:

> Ooops, backtrack this: something is missing in your proposal Doug, that 
I didn't catch before:
> -          remember this is the issue where termination is on sequence 
Fault from RMD side: the 
> RMS does not even get a chance to do some closing.
> -          So I think we should also give all Sequence Faults a 
"closing" semantics, rather than 
> an actual "termination" semantics. When getting the Fault, the RMS knows 
the sequence has closed, 
> but can still send a "close" op to get a final Ack. Then it would have 
to Terminate the sequence 
> (unless it lets inactivity or expiration time kick-in).
> -          Your proposal seems to be more appropriate for the twin issue 
 - reworded Proposed-01 
> -, where RMS just wants the final tab after deciding to not use the 
sequence anymore, regardless 
> of gaps and regardless of termination process (expiration, inactivity, 
or TerminateSequence if allowed here)

I agree, IMO, i019's title should possibly better reflect the description, 
which clearly suggests
that it is concerned with faults generated by the RMD. I would proposed 
re-titling the issue:

        i019    Sequence termination on RMD generated Fault 

I agree that much of the discussion here is probably more relevant in the 
context of 
proposed issue 01 for this week's call.

        
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00084.html

With that said, I still have further comments below.

> 
> Jacques
> 
> 
> From: Jacques Durand 
> Sent: Tuesday, August 16, 2005 3:20 PM
> To: 'Doug Davis'; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i0019 - a proposal
> 
> Doug:
> 
> Overall that seems to do the trick.
> More Inline <JD>
> 
> A related comment:
> 
> -          the use of LastMessage marker appears now like a subcase of 
closing, where the RMD will
> close if (1) LastMessage was received, (2) all messages before were 
received.
> -          After we are done with i019, I think we should reconsider how 
useful LastMessage is (I 
> guess a separate issue). My expectation here is to keep the protocol 
simple. At least, I would 
> like i019 and your proposal to NOT be perceived as making the protocol 
more complex... as I 
> believe it makes it possible to trade one feature ("LastMessage") for 
another ("Close").

Hmmm... I would be more inclined to eliminate LastMessage, as part of the 
proposal to close
whichever issue this is related. That way, it can be analyzed in its full 
glory. I too see 
Close() as a replacement for <LastMessage/>. read on...

> 
> Cheers,
> Jacques
> 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Sunday, August 14, 2005 4:26 PM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] i0019 - a proposal
> 
> 
> For issue 19 we're really dealing with the communication of the state of 
the sequence between the 
> RMD and the RMS.  I think there are two situation we need to think 
about: 
> 1 - a sequence w/o gaps 
> 2 - a sequence with gaps 
> 
> #1 is easy, when the RMS receives an Ack for the full range of messages 
that it has sent then it 
> knows that the sequence is complete and it can send a Terminate knowing 
no new messages will be 
> accepted by the RMD.  In the absence of an ACK the RMS can always ask 
for one using an 
> AckRequested thereby determine the RMD's state. 
> 
> #2 seems to be the problem child.  Lost (or delayed) Acks and Messages 
can play havoc with the 
> RMS's perception of what the final state of the sequence is.  For 
example, it may believe that 
> message #3 (out of 6) was lost and doesn't care any more (for some 
reason), so it sends a 
> TerminateSequence. 
> 
> <JD> I thought TerminateSequence can't be sent out unless RMS get all 
messages acknowledged ? 
> (hey, I am not the only one reading the spec in a "lax" way !! ;-)

Let us assume that for purposes of discussion, #2 is taken in the context 
of an RMS generated
fault that results in premature termination of the Sequence by the RMS, 
yet it wants an accurate
accounting of the final state as perceived by the RMD and it wants to 
ensure that no further messages
are processed.

> 
>  However, if message #3 is just slow, and arrives at the RMD after the 
sending of the Terminate 
> but before it arrives then the RMD's sequence state will differ from the 
RMS's.  Sending a final 
> Ack back to the RMS might not be sufficient since that might be lost as 
well. 
> 
> <JD> In fact, the termination case for i019 is more of a SequenceFault 
that, at the time it occurs
> on RMD, leaves the RMS without an idea whether some missing messages 
were received since it got 
> its last SequenceAck. But the solution is the same.
> 
> 
> So, I'd like to propose the following: 
> 
> Add a "Final" marker to the SequenceAck header (per Dan's suggestions). 
The inclusion of this 
> element in the Ack is the RMD's way of telling the RMS that no new 
messages will be accepted into 
> this sequence.  This is true regardless of there being gaps in it or 
not. 
> Define a new operation: "Close".  The RMS can send a "Close" to the RMD 
indicating that it would 
> like to shutdown the sequence and request that no new messages be 
accepted.  Notice that this is 
> similar to a TerminateSequence in that they both shutdown the sequence 
but unlike a TerminateSeq, 
> the "Close" will not do any resource reclamation - it just halts the 
delivery/processing of any 
> new messages. 
> 
> <JD> semantics of Close is: sequence will reject any future message (in 
effect freezing its state)
> except "operation" messages such as Close and TerminateSequence, to 
which it should respond as appropriate.

I think more correctly, the RMD, upon receipt of a Close() message MUST 
NOT process any subsequent
messages received for that Sequence that have a wsrm:Sequence header block 
belonging to the closed
Sequence.

> 
> 
> So, going back to situation #2, the RMS wants to close down the sequence 
despite there being gaps.
> It will send a "Close" to the RMD, which in turn responds with "Closed" 
plus an Ack.  Note that 
> the Ack will include the "Final" marker. 
> 
> <JD> if the Closed is always accompanied by the SeqAck, then this Ack 
can be considered as final 
> ("Final" marker is only cosmetic).

I disagree, I think that it would be preferable that the 
SequenceAcknowledgement MUST be marked
as "final" to ensure that there is no ambiguity... the SequenceAck *could* 
technically just be
piggy-backed by the implementation and represent state that is not, in 
fact, final. I believe that
we would be better served leaving no doubt by making it a requirement that 
the SeqAck be marked
"final".

> 
>  If this message (or the Close) is lost the RMS is free to send it over 
and over until it gets an 
> Ack+Final since processing multiple ones has no negative impact.  Upon 
receipt of the Ack+Final 
> the RMS can then safely send a TerminateSequence without fear of any new 
messages arriving and 
> changing its perception of the gaps in the sequence. 
> <JD> that means we change the rule of usage for TerminateSequence too.

I don't quite understand. What rule? To the best of my knowledge, there is 
nothing in the spec
that says that the TerminateSequence for a given Sequence MUST NOT be sent 
more than once by the
RMS. However, I could see utility in making it clear that both Close() and 
TerminateSequence()
are idempotent operations and MUST be implemented as such.

> 
> 
> Note that sending a "Close" for a sequence that doesn't have gaps 
doesn't cause any harm either - 
> its an optional message that _can_ flow right before a 
TerminateSequence. 
> Thoughts?  If people like this I'll write up a more formal proposal 
(spec changes). 
> 
> <JD> I'm OK with this.
> -Jacques
> 
> 
> thanks 
> -Doug