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: [no subject]


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]=20
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=20
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,=20
e.g. between the sending of the last SequenceAcknowledgement and before
the reception of=20
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=20
"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=20
the RM Destination terminates the sequence (either at reception of
TerminateSequence,=20
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]