OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019


Title: RE: [ws-rx] NEW ISSUE, twin sister of i019

Chris:

Maybe I am a bit obtuse here but I just did not take that whole statement itself in an exclusive way (notwithstanding my notion of "complete" which was as good as in dictionary.reference.com)... I guess the "what is not forbidden is allowed" perspective. So I think some editorial tightening would help folks like me :-)

 May I add, precisely because it is only about enabling RMD to efficiently reclaim resources associated with the Sequence, I saw use cases where  using <TerminateSequence> may be as legitimate for an incomplete sequence as for a complete one. So I guess that is these use cases that need be discussed - (let me download that Gil doc...)

Thanks,
Jacques



-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, August 11, 2005 6:21 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019

Jacques,

The spec says at line 569:

"After an RM Source receives the <SequenceAcknowledgement> acknowledging
the complete range of messages in a Sequence, it sends a  element, in the
body of a message to the RM Destination to indicate that the Sequence is
complete, and that it will not be sending any further messages related to
the Sequence. The RM Destination can safely reclaim any resources
associated with the Sequence upon receipt of the  message."

The key word in the first sentence is "complete", wherein the definition
of "complete" in this context is the fourth one here:
        http://dictionary.reference.com/search?q=complete

        4. Absolute; total

I always thought that it was pretty unambiguous, but maybe I am mistaken
and it should instead read:

After an RM Source receives the <SequenceAcknowledgement> containing a
single <AcknowledgementRange> element with an @Upper valued at the
MessageNumber of the <LastMessage> in a Sequence and the @Lower valued at
"1".

That was certainly the intent.

The statement at 569 is followed up starting at line 580 with:
"/wsrm:TerminateSequence
        This element is sent by an RM Source after it has received the
final <SequenceAcknowledgement> covering the full range of a Sequence. It
indicates that the RM Destination can safely reclaim any resources related
to the identified Sequence. This element MUST NOT be sent as a header
block."
This reinforces what I claimed on the call, that the purpose of
TerminateSequence is to allow the RMD to reclaim any resources
associated with the Sequence. It means that the RMS is done, finit, kaput
with that Sequence.

I don't think that you should read into a spec, content which is simply
not there:

> I did NOT interpret it as:
>
> " an RM Source MUST NOT send <TerminateSequence> in other cases where it
has not received full
> acknowledgement of the complete range of messages in a Sequence."

But, maybe that is what is needed:

"An RM Source MUST NOT send a <TerminateSequence> if it has any
expectation of ever receiving information from the RM Destination
about that Sequence after the <TerminateSequence> is transmitted."

Again, the purpose of the <TerminateSequence> is to enable the RMD to
efficiently reclaim any and all respources associated with
the Sequence. It isn't necessary that the RMD ever receive this message,
as the resources can still be reclaimed either at the Sequence expiration
time or following a duration of inactivity, etc. However, the
<TerminateSequence> message's purpose seems clear, to me at least.

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/11/2005 08:16:56 PM:

> Giovanni:
>
> I think you are right on the spot about the misunderstanding that we had
in the conf call today.
> Indeed, I interpreted this statement of the spec as nothing more than
the normal use for
> TerminateSequence, non-exclusive of other uses:
>
> "After an RM Source receives the <SequenceAcknowledgement> acknowledging
> The complete range of messages in a Sequence, it sends a
<TerminateSequence>
> element, in the body of a message to the RM Destination to indicate that
> the Sequence is complete, and that it will not be sending any further
> messages related to the Sequence."
>
> I did NOT interpret it as:
>
> " an RM Source MUST NOT send <TerminateSequence> in other cases where it
has not received full
> acknowledgement of the complete range of messages in a Sequence."
>
> Therefore we were not discussing on the same base of premises.
>
> Your speculation is right: I assumed that seq termination (an operation
that is more meaningful to
> RMD than to RMS, given that the ending of a sequence has already been
notified by LastMessage
> sending ) may be appropriate in some cases where not all messages have
been acked. My recent
> rewording of the issue clarifies this a bit, but is still based on the
same interpretation of
> TerminateSequence, so I may need to shelve it and submit an issue on
TerminateSequence instead.
>
> Note: I believe your last paragraph below just illustrates the need for
clearly stating the valid
> use cases as in Gil doc, so that we can sync up on these before even
discussing the issues ...
>
> Regards,
>
> Jacques
>
> -----Original Message-----
> From: Giovanni Boschi [mailto:gboschi@sonicsoftware.com]
> Sent: Thursday, August 11, 2005 3:47 PM
> To: Jacques Durand; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] NEW ISSUE, twin sister of i019
>
> From the issue justification, "The specification is too lax on the
> loophole that permits stray messages to
> "sneak-in" just before a termination, without any opportunity to be
> acknowledged"
>
> This is what the specification says:
>
> "After an RM Source receives the <SequenceAcknowledgement> acknowledging
> the
> complete range of messages in a Sequence, it sends a <TerminateSequence>
> element, in the body of a message to the RM Destination to indicate that
> the
> Sequence is complete, and that it will not be sending any further
> messages related to
> the Sequence."
>
> This, at least to me, says pretty clearly that a conformant RMS will not
> send TerminateSequence until all messages have been acknowledged, and
> that it will not send any new messages after sending TerminateSequence.
>
> To be sure, duplicates of messages previously sent (and acknowledged)
> may arrive at the RMD after TerminateSequence.  But these are
> duplicates, not unacknowledged messages.
>
> The specification has a definition of "normal termination" which
> requires that all messages be acknowledged, and therefore the "situation
> whereupon normal termination of a sequence some messages that were
> previously send and never acknowledged..." is, by definition,
> impossible.  The "accuracy of acknowledgments upon normal sequence
> termination" is 100% perfect.
>
> Now, during the call today, Jacques seemed to suggest that what was
> behind this is that a sender may need/want to terminate the sequence
> prior to all messages being acked; this may well have merit, or at the
> very least is worthy of discussion; the current spec clearly does not
> allow it, and it is well within the responsibility of the TC to consider
> such a change.
>
> But if the request is to change the definition of sequence termination,
> or maybe to provide an additional type of termination, the issue
> description should clearly say just that ("we should allow for normal
> termination prior to acknowledgement of all messages"); but nothing in
> the text of the issue suggests that we are looking for a change in
> definition of normal termination.
>
> I don't know whether procedure allows revising the text of the issue for
> clarity.  As it stands now both the description and justification below
> contain statements that appear to me to be factually incorrect, or at
> best highly misleading.  It should not be surprising that this generates
> long discussions in the confcall about whether to even accept it as an
> issue.
>
> I will speculate that I may have an idea of what Jacques may be after:
> a sender may, for a variety of reasons which we could discuss (e.g. it
> is being shut down for maintenance longer than the sequence expiration),
> be forced to stop resending; if so, it would be nice to know which
> messages actually got delivered or didn't, so that it may send the
> undelivered ones again later in another sequence w/o duplicating them.
> AckRequested does not serve this purpose because, unless the sequence is
> actually terminated, there may be more message out there in flight which
> will actually arrive at the RMD and be delivered.  But I'm just
> speculating, the issue doesn't say that.
>
> Jacques, please clarify.
>
> Giovanni.
>
> ________________________________________
> From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
> Sent: Thursday, August 04, 2005 6:50 PM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] NEW ISSUE, twin sister of i019
>
> I realize that we should probably discuss this new issue in conjunction
> with i019, i.e. before closing on i019.
> (it is stating a similar problem, but for normal termination cases.)
>
> Daniel:
> With the perspective of this new issue, I am leaning more toward your
> proposal to mark as "last" the final sequence status.
>
>
> Jacques
>
>
> Title: Accuracy of acknowledgement status upon normal sequence
> termination
>
> Description: The specification does not address the situation where upon
> normal
> termination of a sequence, some message that were previously sent and
> never acknowledged
> (for which RM Source had stop any resending effort) has been received
> late by RM Destination,
> e.g. between the sending of the last SequenceAcknowledgement and before
> the reception of
> a TerminateSequence message. This is the twin sister of issue i019 which
> deals with a similar
> problem but in case of fault termination.
>
> Justification: Normal termination is actually a fairly common event
> (compared to sequence fault)
> and it is expected that sequences will be terminated even if they have
> missing messages.
> The specification is too lax on the loophole that permits stray messages
> to
> "sneak-in" just before a termination, without any opportunity to be
> acknowledged.
>
> Target: core
> Type: design
>
> Proposal: A final acknowledgement status could be sent back that
> reflects the exact state
> at termination time. That could be done by sending (or by making
> available for polling
> even after the sequence is terminated) a last SequenceAcknowledgement
> element, at the time
> the RM Destination terminates the sequence (either at reception of
> TerminateSequence,
> or due to timeout). Such a SequenceAcknowledgement element should have a
> "last" marker.
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]