ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i0019 - a proposal: (more complete)
- From: Doug Davis <dug@us.ibm.com>
- To: Jacques Durand <JDurand@us.fujitsu.com>
- Date: Wed, 17 Aug 2005 01:56:28 -0400
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.
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).
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]