Doug:
Inline<JD>
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, August 16, 2005
10:56 PM
To: Jacques
Durand
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a
proposal: (more complete)
If you mean the RMD would resend the Fault +Ack+Final,
or perhaps some other/new SeqClosed Fault +Ack+Final, for any possible new
messages that are received, then yes.
<JD>
yes
And
for the other part, in general yes I think I agree. I need a bit more
time (and sleep) before I'm sure that _all_ faults should close a sequence. I
seem to recall there be some talk about some of them just faulting for that
particular message but still allowing other messages in (like
LastMessageNumberExceeded Fault).
<JD>
In fact, after thoughts very few Faults should be fatal to the sequence:
Closing
the sequence:
-
SequenceTerminated
(actually should rather close than terminate, now that we have that state...)
For MessageNumberRollover,
not even sure it should close: we may still want the RMS to get a chance to get
delayed messages through or just even the recent ones missing that are still in
resending mode. Consider the case where RMS keep sending messages in a
pipeline mode not waiting for the Ack of previous ones. It is quite possible that
the "exceeding" one is received by RMD while some among the previous
ones are still in flight, or being resent. These would never get a chance to
get in. So this fault should actually not close the sequence: it would be up to
RMS to decide when to close (or not) some time after getting the fault. Then it
get its final Ack, then terminates.
For LastMessageNumberExceeded,
same thing: although it says to be fatal, I am not sure: after all it should
not prevent previous missing messages to come in after, so I'd prefer the
RMD to consider it a "one message" error and just ignore the faulty
message...
Other
faults should probably not close any sequence.
-Jacques
thanks,
-Doug
|
Jacques
Durand
<JDurand@us.fujitsu.com>
08/16/2005 09:37 PM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS
|
|
cc
|
ws-rx@lists.oasis-open.org
|
|
Subject
|
RE: [ws-rx] i0019 - a proposal: (more
complete)
|
|
Ack+Final returned with a sequence Fault should
then be added to complete proposal - that is indeed an option I saw.
However... even the Fault could be lost, and therefore the
RMS may still try to send messages. I assume then that the behavior is for RMD to
resend the Fault+ Ack+Final each time.
Ø While
the RMS could send a close() to get the final Ack, sending just an AckReq would
do it too.
Right. So I guess we still need to say in update to spec that
sequence faults have the effect of closing the sequence.
(not terminate it).
The statement about semantics of closing becomes:
- no "sequence" message will be accepted anymore. If the
sequence was Faulted at time it closed, the sequence Fault will be resent back
(according to policy) if RMS keeps sending messages, and if so, must
always include Ack+Final.
- All sequence operations are still accepted and processed as
appropriate, until termination occurs.
Thoughts?
-Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, August 16, 2005 5:40 PM
To: Jacques Durand
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
I don't think I was totally clear - I viewed them as being the same thing
because (and this is where I probably wasn't clear) on a Fault I assumed the
RMD would close the sequence and send back a Fault with the Ack+Final (which is
what you say in your 2nd bullet). While the RMS could send a close() to
get the final Ack, sending just an AckReq would do it too. So, whether the two
issues are the same or not I view this solution solving both of them.
-Doug
|
Jacques
Durand
<JDurand@us.fujitsu.com>
08/16/2005 07:50 PM
|
|
To
|
Jacques Durand
<JDurand@us.fujitsu.com>, Doug Davis/Raleigh/IBM@IBMUS,
ws-rx@lists.oasis-open.org
|
|
cc
|
|
|
Subject
|
RE: [ws-rx] i0019 - a proposal: (more
complete)
|
|
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)
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").
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
!! ;-)
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.
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).
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.
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