To summarize where we are I think in
resolving i019 and Proposed-01:
Consensus on:
(a) [for i019] A final SeqAck tagged "final" sent by RMD
when it closes a sequence on Fault . The RMS may query to get this Ack again.
(b) [for Proposed-01] A new "Close" operation (idempotent) for
the RMS to freeze the state of a sequence on RMD and return a final Ack.
Still on the table:
(c ) [improving by simplifying] removing
LastMessage feature, as it is kind of subsumed by (b) above.
(d) [needed by i019 to allow querying
again for Ack] Sequence faults do not terminate sequences anymore. At best,
they "close" them.
(e) [improving fault termination case] Sequence
Faults to not even Close a sequence (except for "SequenceTerminated"
fault) (see my recent mail to Doug D.) Most faults are "message-scope"
faults not affecting seq integrity if message ignored. RMS has now choice to
close or not a Faulted sequence.
(f) [just a resource mgt issue for
special case] Use of TerminateSequence by RMS authorized even on non-complete
sequences, assuming they have been Closed.
Do we agree on this status?
Jacques
From: Jacques Durand
Sent: Thursday, August 18, 2005
11:33 AM
To: 'Christopher B Ferris';
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a
proposal: (more complete)
Chris:
Extracting
some of your answers from the logbook...
>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.
I think
that's a precise statement for describing the Closed semantics.
>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/>.
That is
what I meant. I am all in favor of removing LastMessage feature in this
resolution, if that's not too much to do for closing this issue.
>i019
Sequence termination on RMD generated Fault
Better
than current title, though I was also pleased with my own proposal in a past
mail:
- I019: "Accurate final
acknowledgement of a Sequence terminated on Fault by RMD"
- Proposed-01: "Accurate final
acknowledgement of a Sequence with gaps when RMS decides to stop using
it."
...
>I disagree, I think that it
would be preferable that the
> SequenceAcknowledgement MUST
be marked as "final" to ensure that there is
> no ambiguity...
Sounds
good - indeed otherwise there may be some corner cases.
>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.
I meant
the rule that TerminateSequence can only be used on fully acknowledged
(complete) sequences. It is definitely OK to send any of these ops more than
once. Idempotency reflects also in what is returned by these ops, if
applicable.
Cheers,
Jacques
-----Original
Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, August 18, 2005
9:24 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a
proposal: (more complete)
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