[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] PR Issue 22: concrete proposal
Current spec: "<CloseSequence> indicates that the RM Destination MUST NOT accept any new messages for the specified Sequence" Observe: if RMS issues CloseSequence before receiving all the acks, RMS is implying that is is not interested in completing current sequence as is. Implications: - if RMS wants to complete the sequence, it MUST NOT issue CloseSequence until RMS receives all the acks. - if RMS does not want to complete the sequence, then (a) it is because AS doesn't care, in which case there is no error and there is nothing to log on RMD side and AD doesn't care either, or (b) RMS intends recovery by analyzing FinalAck and placing un-acked messages into a new sequence; once again any logging or other RMD action are spurious, since "protocol" hasn't completed yet. - if RMD does not care (by configuration) about completing incoming sequence, there is no error to log if sequence is incomplete - if RMD does care about completing incoming sequence, RMD needs to force certain behavior out of RMS, namely, RMS waiting to issue CloseSequence until RMS receives all the acks, perhaps, through the use of an appropriate policy assertion. then, if RMS is compliant, receipt of CloseSequence indicates to RMD that sequence is complete and HighestAssignedSeqno field provides no additional value. Conclusion: HighestAssignedSeqno is useless. Durand, Jacques R. wrote: Gil: inline -----Original Message----- From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] Sent: Wednesday, November 15, 2006 2:51 PM To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Jacques: Point by point: (1) It's not clear whether you support LastMsgNumber as a MUST in TerminateSequence. The requirement for supporting this depends upon the requirement for sending CloseSequence. <JD> Given that we seem to agree on (2) below, I think we don't need to make LastMsgNumber mandatory in TS - it should normally be always communicated via CloseSequence. (2) If it would allay your concerns, I would support the notion of adding a "Advize" value to IncompleteSequenceBehavior. The algorithm would be, if IncomplateSequenceBehavior=[DiscardEntireSequence | Advise], then the RMS MUST send a CloseSequence message. What do people think about this? <JD> I find this reasonable. (3) While I think Bob's idea of requiring the CloseSequence message to be treated like a Sequence Traffic Message is interesting, it represents too great a change to make at this time. I'm also against the idea of requiring the RMS to retry either the CloseSequence or TerminateSequence messages although we could note that an RMS MAY do so if it's willing to handle the possible fault(s) that may result. <JD> Not saying anything in the specification about this is fine. An RMS that needs a final Ack will normally send CloseSequence and repeat it if needed to get this finalAck along with the ClSR. This repeat is not required, but supported by those who care about this feature. Same here: could be controlled by some out-of-scope policy detail that only recommends a level of retries, for those who care. Bob's idea, regardless of its merits, brings change to the model of separation traffic/lifecycle message, and may have ripple effect throughout the spec. -Jacques - gp-----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Tuesday, November 14, 2006 8:14 PM To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Gil: I see three aspects in your proposal that need to be looked at - or agreed on: (1) Whether the LastMsgNumber is a MAY or a MUST in CloseSequence. (2) Whether the CloseSequence message MUST be sent by the RMS (or MAY, as of today). Similar issue with TerminateSequence. (3) Whether any extra effort may be required to ensure the reception of this LastMsgNumber marker, which is important after all to your goal. On (1), based on off-list conversations in our little task force, I have no qualms anymore making it an unconditional MUST. We see this creates no extra burden on an implementation and that reduces the number of options. In the same way as CloseSequence is the means to query a final ack (for whatever use it serves), we could just decide it is also the means to communicate a final sequence account. So fine. On (2) I am not comfortable making this an unconditional MUST as a general rule. After all, in many cases (where precisely the RMD awareness you want to support is not required) the RMS should not have to bother sending these lifecycle messages. But I think you could achieve your goal at protocol level (without conditioning this MUST to an external agreement or DA), by relying on IncompleteSequenceBehavior (ISB). Clearly if ISB is DiscardEntireSequence, it makes sense that RMS be required to always close such sequence. We could imagine another value for it like "JustAwareness" that does not discard the sequence but requires awareness of incompleteness, meaning also required closure. On (3), I'd say some retry of CloseSequence would be expected but should not be more specified than the retry of traffic messages - left to external policy / agreement. Bob's solution is tempting, but need to look at the implications of making a lifecycle message also be a traffic message. Now I think if you add a Sequence header to CloseSequence, you do not need anymore LastMsgNumber... Jacques -----Original Message----- From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] Sent: Tuesday, November 14, 2006 3:27 PM To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Jacques: You are right, there is a difference between (b) and (a). In my mental model (b) is inclusive of (a). That is to say, whenever the "all messages received scenario" (described) below occurs, the RMD knows that it has received all the messages that were sent. I think we are in agreement about the expected behavior of both the RMS and the RMD, we just need to agree on the language to describe it. - gp-----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Friday, November 10, 2006 7:48 PM To: Gilbert Pilz; Stefan Batres; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Gil: Actually, your initial goal as stated in your proposal: (a) " [In order] to allow the RM Destination to determine if it has received all of the messages in a Sequence,..." Is not quite the same as: (b)All we want is for the receiver to have the ability to determine if this scenariooccurred or if itdidn't The difference between these, is that in (b) you do not care at all about receiving a TS/CS or not (in case not, the scenariojust did notoccur...), while in order to achieve (a) you absolutely need a TS+LM or a CS+LM, otherwise you can NOT determine if the messages you received form a completesequence. Nowwe know that this last goal (a) is not always achievabledue to lossof CS/TS. But we know it is desirable that the protocoldoes its bestto ensure it. Which is why Stefan's question is legitimate. Let's assume (a). My take on this, is: - an implementation should not be required to do this extraeffort ofresending CS or TS (concede it may not be clear in myprevious mail).- in case an implementation decides to support this extra effort (controlled by an external agreement, like details oftraffic messageresending), it is sufficient to do resending of CS, not of TS. - In all cases, and RMD implementation never needs to keep sequence state after it got the TS. Not sure where the "overkill" is :-) Jacques -----Original Message----- From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] Sent: Friday, November 10, 2006 3:36 PM To: Durand, Jacques R.; Stefan Batres; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal This is a giant overkill. Consider the following scenario: 1.) RMS and RMD exchange CS/CSR2.) RMS sends a number of messages. Very few, if any, are lost. 3.) RMD acks the messages. 4.) RMS re-sends any messages that aren't acked; RMDeventually getsthem and acks them. 5.) RMS and RMD exchange TS/TSR. I would argue that this scenario will apply to an overwhelming majority of the WS-RM Sequences that are ever created. Allwe want isfor the receiver to have the ability to determine if this scenario occurred or if it didn't. It's a very simple idea. If some of the messages never get through (including CS or TS) that falls into the "something went wrong with the Sequence" bucket. - gp-----Original Message----- From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: Thursday, November 09, 2006 3:29 PM To: Stefan Batres; Gilbert Pilz; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Stefan: In the light of today's discussion, and looking at this from an "agreement" perspective, where the requirement for an RMDto notifyits party if it missed any message in a sequence isconditioned by an[out-of-scope] agreement that would be known from both parties: - if there is such an agreement, then I would assume the RMS must ensure the RMD got its LM (and if it failed to do so,should notify,etc.) But this agreement could mean for RMS to do LM inCloseSequenceand retry as much as needed, until getting the CSR, instead of focusing on TS. That seems more appropriate because thetime between aCloseSeq and a TS is precisely intended for both partiesto get insync. - It does not have to mandate more from TS/TSR, whichwould be moredemanding on implementations: if RMD sent its TSR, itshould be freeto reclaim resources immediately, regardless if RMS gotit. RMS maytry to resend TS with no success but there is no harm:TS/TSR are justresource optimization features as before, once LM has beensecured byCloseSequence exchanges. -Jacques -----Original Message----- From: Stefan Batres [mailto:stefanba@microsoft.com] Sent: Thursday, November 09, 2006 1:00 PM To: Gilbert Pilz; ws-rx@lists.oasis-open.org Subject: RE: [ws-rx] PR Issue 22: concrete proposal Gil, This seems sane too me. I do have an issue that is not directly related to PR0022 but seems somewhat related to how we address it. With the spec as-is and with your proposed changes wedon't have aquick resource reclamation mechanism like we did in the submitted spec. For example: I am an RMS. I send one of these TS with LM. Should I retry if I don't get a response? Probably yes. You are an RMD. You get my TS with LM. You send a TSR. Since the TSR might get lost, and because I might retrythe TS, youshould be ready to respond to my TS retry. How long do you remember the sequence in case I retry? In the submitted spec, if you got the TS you couldimmediately forgetabout the sequence and never respond again. This workedbecause we putthe LM in a Sequence header. Thanks --Stefan -----Original Message----- From: Gilbert Pilz [mailto:gpilz@bea.com] Sent: Thursday, October 26, 2006 12:49 PM To: ws-rx@lists.oasis-open.org Subject: [ws-rx] PR Issue 22: concrete proposal Attached is a proposal for PR i022 in the form of a diff against CD-04. The main points are: 1.) wsrm:TerminateSequence has been expanded to include amandatoryLastMsgNumber element the value of which is, surprisinglyenough, thenumber of the last message in the Sequence. 2.) Sending wsrm:TerminateSequence is now mandatory;basically thewhole thing won't hold together unless the RMS is requiredto send awsrm:TerminateSequence. <<wsrm-1.1-spec-pr-i022.pdf>> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]