[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] New proposal for i019 and i1028
All,
Thank you for your feedback.
I stand corrected - this proposal doesn't address i019. I will work on a
revised version that takes care of that.
The proposal does address i028. If an RMS wants to gracefully end a
sequence for which it does not have a full ack set it can send a
stand-alone Sequence message with the LastMessage element and a
SeqCancel header indicating the messages for which it doesn't have an
ack. The RMD then sends a SequenceAck with an acknowledgement set that
includes the LastMessage and a SeqCancelAck. When the RMS sees this
message it knows the outcome of every message in the sequence and can
send a SequenceTerminated.
Anish is right in that use cases need to be identified for resolving
doubt without ending sequences ("pull out a message and continue using a
sequence"). I will file an issue with use cases for that (call this i0XX
for now).
Doug (Davis) also suggested that if there are use cases for gap filling
I should probably file an issue. I will do so (call this i0YY for now).
The revised proposal would address i019, i028, i0XX and i0YY. As such, I
will correct myself and retract the idea that this proposal is a strict
alternative to Doug's Close proposal. I think it will make sense to make
a deep analysis of this proposal only if and when i0XX and i0YY are
filed and accepted by the committee.
Thanks,
--Stefan
-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Thursday, September 15, 2005 12:42 AM
To: Stefan Batres
Cc: Doug Davis; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] New proposal for i019 and i1028
Stefan,
Issue 19 is about RMD deciding to terminate a sequence (for whatever
reason) but doing a graceful shutdown (providing information to the RMS
about which messages were received, allowing the RMS to rollback or take
app level actions if needed).
Issue 28 is about RMS deciding to terminate a sequence (for whatever
reason) but doing a graceful shutdown (asking RMD to provide its status
and not delivering any laggard messages, allowing the RMD/RMS to
rollback take ack level actions if needed).
Doug's proposal [1] does address the two issues.
What I understand of your proposal is (pl. correct me if I didn't grok
it correctly or missed something):
1) It allows RMS to 'cancel' message(s) without shutting down the
Sequence. RMS is free to send additional new messages.
2) Since the Sequence is not shutdown, such cancels over time may result
in lot of gaps. This will make the Ack quite unwieldy. So the proposal
allows RMS to fill those gaps. I view this as an optimization (although
an appropriate one if we do have a 'cancel')
What this means is:
1) There is no mechanism for the RMD to to a graceful shutdown and
provide status to the RMS. I.e issue 19 is not addressed by your
proposal.
2) This fundamentally changes the protocol AIUI. Currently the protocol
is AtLeastOnce on the wire. Now, there may be messages in the Sequence
which are recalled, if not delivered (the message goes into witness
protection plan -- never existed).
The two issues as filed and discussed are about how to deal with faults
(running out of resources) and abnormal Sequence terminations
gracefully. Doug's proposal does not change the situation that once
either RMS or RMD gets into that situation the Sequence is terminated.
It just provides protocol elements to communicate RMD's state back to
the RMS for subsequent action if necessary.
I think what you are talking about is a scenario where the RMS want to
pull out a message (if undelivered) and continue using a sequence. I
would suggest sending a usecase for this and perhaps filing a new issue.
I see this as a completely different issue.
For example, one usecase could be: it may be that the RMS that does not
have a large stable storage, fails and recovers. It may have enuf stable
storage to remember the Sequence id/last message number but does not
have access to un-Acked messages anymore. The RMS still wants to
continue using the same Sequence but does not have the ability to
retransmit old messages and therefore wants to cancel unreceived
messages. I'm not convinced that such a usecase makes sense (but haven't
thought a lot about it) -- if RMS fails and cannot recover unacked
messages, that is a fault and the Sequence should terminate.
Regardless, I see this as a separate issue/usecase and I would like to
suggest that it be considered as such.
HTH.
-Anish
--
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509
/msg00084.html
Stefan Batres wrote:
> Doug,
>
>
>
> Thank you for your careful review of this proposal. I have some
comments
> regarding some of the points you make and I'm also including answers
to
> some of the detailed questions you've made.
>
>
>
> I will propose a new issue relating to gaps.
>
>
>
> Cancel relates to i019 and i028 to the same degree as Close does
because
> it addresses them in the same way; by providing a mechanism that an
RMS
> can use to end a sequence with a final and accurate ack set. Attached
is
> an example of how to do this using Cancel.
>
>
>
> Cancel addresses a superset of the issues addressed by Close; i019,
i028
> and the yet-to-be-named issue related to gaps.
>
>
>
> I don't expect Cancel to change the protocol at all but rather to just
> add to the protocol. In fact, it could plausibly be its own document
(I
> not advocating for or against that, I'm just making a point).
>
>
>
> I acknowledge that the amount of sequence state Cancel adds is a
> concern. I think the benefits of factoring the mechanisms used to end
> sequences and resolve doubt independently outweigh these concerns.
This
> clean factoring could potentially allow for different levels of
support
> allowing for someone to support only sequence termination with a final
> accurate ack set and not incur any extra state management. I have to
say
> I need to give this "different levels of support" idea some further
> thought since I just thought of this as I read your comments.
>
>
>
> If a new issue is opened and accepted, then, since Cancel addresses
> i019, i028 and i0<whatever>, I don't see why we'd need Close as well.
>
>
>
> Answers to some of the other detailed questions:
>
>
>
> Q: How does an RMD "never accept messages"?
>
> A: It ignores them.
>
>
>
> Q: Is the SeqCancelAck header on all messages that have a SeqAck
header?
>
> A: No.
>
>
>
> Q: What if the SeqCancelAck is lost? Do we need a CancelAckRequested?
>
> A: RMS can resend SeqCancel.
>
>
>
> Q: How does an RMS know whether a particular message was filled-in or
> cancelled?
>
> A: The RMS is driving; if it wants to know if a particular message was
> captured or not then it should include that message in a SeqCancel
> before including it in a SeqFill.
>
>
>
> Q: What is the distinction between canceling and gap-filling?
>
> A: Canceling, by itself, resolves doubt about the transmission of
> messages. Gap-filling, by itself, fills gaps in the ack set, possibly
> incurring doubt. Canceling followed by gap-filling resolves doubt and
> compacts the sequence state.
>
>
>
> Q: Does filling a gap remove those messages from future SeqCancelAck
> headers?
>
> A: Yes.
>
>
>
> Thanks again.
>
>
>
> --Stefan
>
>
------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Wednesday, September 14, 2005 6:56 AM
> *To:* ws-rx@lists.oasis-open.org
> *Subject:* Re: [ws-rx] New proposal for i019 and i1028
>
>
>
>
> Stefan,
> I'm glad that you guys finally see the need for the proposal. I
> must admit though, I don't see how this proposal actually relates to
> the specified issues. Both issues relate to how an RMS can get a
final
> and accurate accounting of the sequence from the RMD - in one case
> because of a fault and in another because the RMS decides to stop
> using the sequence. This proposal, if viewed as a complete replacement
> for mine does not address these at all.
> Your proposal focuses more on gap-filling (2 variants of it) and
> neither of these is mentioned in the issues. And as such I think a
new
> issue should be opened and this can be offered up as a potential
> solution for it. Once that is done, I then have some comments and
> questions about it:
> - How does an RMD "never accept messages" that have been cancelled?
> Does it throw a fault? Ignore them?
> - Does a SeqCancelAck header get carried on all messages that have a
> SeqAck header? In order for the RMS to get an accurate view of the
> sequence it would need all of this info each time.
> - If 'no', then are you proposing an CancelAckRequested header as
> well since the SeqCancelAck headers could be lost and there needs
to
> be some way for the RMS to ask for it.
> - The SeqCancel and SeqFill headers are not information - like the
> AckReq and SeqAck headers. As Dan noted in [1] dealing with these
> headers when piggy-backed on other messages could be problematic.
> Dan's proposal is that any fault generated by these headers should
not
> influence the processing of the original message - and that implies
> that in some cases the fault may be simply dropped. Which is no
> big deal since these headers are mainly informational anyway. The
> new headers you've introduced are not simply information though -
they
> are critical to the success resolving doubt. In the past I said
that
> the Close() in my proposal could be a header - its just a syntax
> difference. You're proposal makes me realize that it really can't
be.
> The Close(), much like your SeqCancel and SeqFill headers, are much
> more serious than the informationally piggy-backed headers we have
> now. And as such they deserve to be treated with more seriousness.
> - After the RMD receives a SeqFill header how does the RMS know
whether
> any particular message was 'filled-in' or the message was just late
> in arriving at the RMD? Does this mean that to fill a gap, the RMS
> should send a SeqCancel, then wait for a SeqCancelAck, then send
> a SeqFill? Unless the RMS never sent the message, or doesn't care
> that it go there, I don't see what else it could do.
> - The distinction between Cancelling and Gap-Filling a hole in a
sequence
> seems almost arbitrary and redundant. There is no clear way for an
> RMS to know which one to use when.
> - As I read it, the distinction between SeqFill and SeqCancel isn't
clear
> and almost arbitraty.
> - Actually, perhaps you believe that gap-filling is for cases where
the
> RMS never actually sent the message. And while I don't dispute
this
> might be a valid use-case my initial reaction is that this should
not
> be something the spec deals with. We've specifically avoided
having
> the spec talk about things outside of what goes on the wire -
things
> like how the DA might influence the protocol - so following that
same
> logic it doesn't seem right to take into account some processing
> that takes place before the RM logic. If inOrder processing across
> sequences is out of scope then this feels like it should be too.
But
> I need to think more about it.
> - You've introduced quite a lot more data for the RMD and RMS to
manage.
> The RMD must now maintain an ACK list and a CancelList - and both
> must be kept to inform the RMS of the sequence state.
> The RMS must now maintain an ACK list, a CancelList and a Gap-List
-
> and all three must be kept in order for the RMS to have an accurate
> accounting of what happened to each message.
> And merging/reconciling these lists could be quite
> expensive (remember, we introduced Nacks just because one list
could
> be hard for some impls - imagine what 3 overlapping ones will do).
> - You claim that the Close proposal introduces another way of
terminating
> a sequence - this is false. Please explain this by showing me
where in
> the proposal it does this. Terminate does not change at all. The
> proposal simply allows for the RMS to tell the RMD to not accept
any
> more messages for the sequence - that is very different than
Terminate
> which involved resource reclaimation.
> - There is still no mention of how to know for sure which Ack
received by
> the RMS is the final one - which is the point of the Close
proposal.
> - Given the only reason for gap-filling in this proposal is to shrink
the
> SeqAck header, does filling a gap remove it from the SeqCancelAck?
If
> not, this could also continue to grow.
> - This change means that it is impossible to examine a SeqAck header
and
> see which messages were delivered, due to gap-filling. Whilst this
> doesn't break the protocol, it also doesn't help in terms of
debugging
> problems. It doesn't feel right for the SeqAck header to lie about
> which messages were really received, just so it has less entries in
it.
>
> Overall, I think this proposal is addressing a very different set
> of issues from the original one proposed - and does so in a way that
> significantly changes the protocol. I would suggest that you rework
it,
> as Paul Cotton suggested during one of our previous phone calls, into
a
> form that would allow the TC to see the specific spec changes you
want.
> I think that will draw out even more questions than what I've listed
> above.
> And, once that happens I think it will be even more obvious that this
is
> a separate issue from the other proposal so please open a new issue
with
> the use-cases this proposal addresses so the TC can get a more
complete
> view of what is driving this. And in the end I suspect you'll find
that
> both could be needed and we should proceed with the other proposal as
is.
>
> thanks,
> -Doug
>
> [1]
>
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509
/msg00048.html
>
>
>
> "Stefan Batres" <stefanba@microsoft.com> wrote on 09/13/2005 03:49:46
PM:
>
>> All,
>>
>> After much discussion Doug has managed to make me understand his
> reasons for
>> proposing his Close/FinalAck mechanism for addressing i019 and i028.
> We now agree,
>> an accurate acknowledgement state can be helpful in order to resolve
> doubt and in
>> addition, for cases where a sequence must be ended, that
> acknowledgement state must
>> be final. These are preconditions for recovery and the protocol can
> aid in
>> establishing these preconditions.
>>
>> However, we still have an issue with the current proposal [1]. We
> think it
>> conflates the notions of resolving doubt and closing sequences.
> Attached is an
>> alternate proposal that we believe addresses this issue, allows for
> the exact
>> semantics [1] provides and has other advantages. Details are in the
> document.
>>
>> [1]
>
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509
/msg00084.html
>
>>
>> I look forward to the group's comments.
>>
>> Thanks,
>>
>> --Stefan
>> [attachment "WSRM-Cancel.doc" deleted by Doug Davis/Raleigh/IBM]
>
>
>
------------------------------------------------------------------------
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]