ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 29 Aug 2005 20:07:25 -0400
Additional comments inline.
All - any additional comments? I
need to send out 'take 3' tomorrow.
thanks,
-Doug
Jacques Durand <JDurand@us.fujitsu.com>
08/26/2005 08:44 PM
|
To
| "'Giovanni Boschi'"
<gboschi@sonicsoftware.com>, Doug Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [ws-rx] i0019 - a formal
proposal - take 2 |
|
Giovani:
I believe there is more in
what you say below than what is needed to resolve i019 and i028.
I am commenting on some of
your points below - but I believe they can be largely dissociated
from the current issues at hand, and be treated separately.
Regards,
Jacques
From: Giovanni Boschi [mailto:gboschi@sonicsoftware.com]
Sent: Friday, August 26, 2005 9:01 AM
To: Jacques Durand; Doug Davis; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
I don't see the current draft
as directly specifying that acks are "on receipt", although clearly
an implementation could take that approach, and it's probably the more
intuitive one - but, specifically I think the current draft allows an RMD
to defer acking until the messages are "in order" i.e. not acking
those messages that are still sitting "behind gaps".
<JD> this is a very important
point to clarify. What you are in effect suggesting, is an Ack on delivery
(since once in order, they can be delivered.). But the spec is clear:
Acknowledgement: The communication from the
RM Destination to the RM Source indicating the successful receipt of a
message. (and in the messaging
model, there is a clear distinction between Receipt and Delivery, see Fig
1)
<dug> +1, current spec is for Ack
on receipt not delivery </dug>
There is a specific benefit
to the "ack when deliverable" (note deliverable, not delivered)
approach for low-resource situations (I can elaborate if needed, let me
know), so I would hesitate to assume that ack-on-receipt is the model used
by all implementations at all times.
<JD> Join the club. I
have been favoring "ack on delivery" from the start, but that
seems to clash with the WS-RM model: the protocol would become involved
in the RMD-AD delivery assurance. Please try to convince Chris...
<dug> I'm staying out of this one
for now :-) </dug>
Now, of course, if my "ack
when deliverable" approach is in use by the RMD, then the final ack
will be accurate: all the messages that have been acked are safely
deliverable after a close. It's the "ack immediately on receipt"
approach that has that problem - but to be clear, I do not want the spec
to impose an ack strategy, I think the freedom the spec gives the RMD on
choosing an ack strategy is one of the coolest things in the current spec.
<JD> well... too much
choice is not necessarily good here: an RMS must preferably know what Ack
means to the other party. I prefer the spec to be clear one way or the
other about this. I think it is now. Just not the way I prefer - because
as drafted today, I maintain, it is OK to acknowledge a message that will
never be delivered, and there is no provision for the RMS to know about
this. But that is another issue.
<dug> I seem to recall the notion
of having some sort of handshaking going on during the CreateSequence where
the RMD would communicate the DA in-use back to the RMS. I suppose
the spec could also communicate the ACK strategy as well, if there was
more than one choice. Not really sure I'd want to offer more than
one but its something to think about </dug>
I think the general way out
of this may be the following: If the original use case was "I
want to close the sequence and have an accurate final ack so I know which
ones to resend in a different sequence later", then it seems to me
that this is really only viable for sequences that do not have InOrder
requirements: If I will send some of them in sequence S2 later there
is no guarantee that they will be delivered in order with respect to the
ones I sent in sequence S1 earlier, and I am going to break the InOrder
requirement anyway.
<JD> I think if InOrder
is required but not AtLeastOnce, that means we accept message loss - and
therefore we would not have any qualms not resending these in S2. Even
if InOrder+ AtLeastOnce is required, some gap may still be there when closing
the sequence S1. But again, S2 can forget about the missing messages in
S1: the DA is still satisfied if a delivery failure has been notified for
the missing,
<dug> A while ago there was a discussion
about how to handle the linking of sequences for cases where the MaxMsgNum
was hit. While there wasn't a formal decision by the TC, quite a
few people said that that notion was something that should be done at a
higher level. I believe the notion of how to recover a sequence when
it is closed prematurely fits into that category as well. So, while
I can see your point about there still being an issue of how to safely
do some recovery, I think its another issue. This current proposal
simply focuses on how the RMS can get an accurate accounting of the 'current'
sequence when it is closed down early. What it does with that info
- if anything at all - is something else. And personally, while I
do agree there is some higher-level processing that can/should take place
in some situations, I do think the RM protocol could help make that processing
easier - but as I said, that's another issue. </dug>
The RMS knows from the final
ack which messages the RMD "has"; if it knew the the RMD<->AD
DA, then it would know what to do:
-
If
the DA is InOrder, it knows that it cannot close and then restart a new
sequence at all without violating the underlying ordering requirements
-
If
the DA is not InOrder then it can close and restart a new sequence later,
and if so it should resend all messages not in the final ack.
<JD> These behaviors
are somehow out of scope of the spec: there is no requirement on dealing
with missing messages across sequences. That is an optimization that
can indeed rely on out-of-band knowledge of the DA.
<dug> yup - current out of scope
or that 'higher level' thing I mentioned </dug>
But, the RMS does not know
the RMD-AD DA; I guess we could propose that the target endpoint publish
its DA in its policy (or createSequence, whatever), and I personally think
it would be a good thing even for unrelated reasons - but I suspect there
could be a lot of opposition - You have to go back to a 2002 version of
the member submission to find DA in the policy, and I think this was removed
very much intentionally. But maybe we could propose it and see?
A minor point on wording: I
think rather than "MUST not accept" we should say "MUST
not deliver to the AD" as in the original text below - "accepting"
is not something that we define anywhere and it could be misconstrued.
Not delivering is what matters.
<JD> Right for the loose
terminology. But again, you are opening a can of worms: we do NOT want
these messages to be acknowledged (not juts "not delivered")
as soon as the closing is effective. Maybe this would do: ...RM
Destination MUST NOT acknowledge nor deliver any received messages with
a Sequence header for the specified sequence, other than those already
received at the time the <wsrm:Close> element is processed by the
RMD
"-Jacques
<dug> Well, it can still deliver
old messages to the AD it just can't ACK new ones. For example, if msg
3 out of 5 is missing and a Close() comes in, the RMD can still deliver
1 and 2 to the AD (if it hasn't done so already). It just can't deliver
4 and 5. I think 'accept' is the right choice.</dug>
G.
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, August 25, 2005 9:36 PM
To: 'Doug Davis'; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
Inline <JD>
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005 5:59 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
When InOrder DA is used the RMS knows that all messages after the first
gap were not delivered to the RMD's application - even if they were ACKed.
<JD> InOrder DA in itself
does allow delivery of non-contiguous messages ( "...it says nothing
about duplications or omission..." Section 2, Core spec)
So, getting an ACK+Final guarantees
to the RMS which messages were not just ACKed but delivered - and any messages
after the first gap can be recovered (e.g. resent in a new sequence if
it wants) without fear of them being processed twice by the RMD's app.
Actually, thinking about it more, perhaps some of the text should remain,
like:
When a Sequence is closed and there are messages at the RM Destination
that are waiting for lower-numbered messages to arrive (such as the
case when InOrder delivery is being enforced) before they can be
processed by the RM Destination's application, the RM Destination
MUST NOT deliver those messages.
Just to ensure that the RMD does not interpret the Close() as the
trigger to let all messages after the gap thru to the app.
thanks,
<JD> but again, because
the semantics of Ack is just "on receipt" and not "on delivery",
an honest RMD developer may decide to Ack these late messages, rendering
the final Ack incorrect (or unstable, depending when it is requested...).
Another way to avoid adding this text is to make the statement below more
general, not limited to "new application messages":
"...can
send a <wsrm:Close> element, in the body of a message, to the RM
Destination to indicate that RM Destination MUST NOT accept any new application
messages for the specified sequence."
Replace with:
"...can
send a <wsrm:Close> element, in the body of a message, to the RM
Destination to indicate that RM Destination MUST NOT accept any application
messages for the specified sequence, other than those already received
at the time the <wsrm:Close> element is interpreted by the RMD."
-jacques
-Doug
"Giovanni Boschi"
<gboschi@sonicsoftware.com>
08/25/2005 08:48 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
"Jacques Durand" <JDurand@us.fujitsu.com>
|
cc
| <ws-rx@lists.oasis-open.org>
|
Subject
| RE: [ws-rx] i0019 - a formal proposal
- take 2 |
|
If the RMD has already acked the out-of-order messages (and the spec at
this point doesn't say it can't or shouldn't), and we then preclude the
RMD from delivering them, then the final Ack is not accurate, which I thought
was the original goal. Even if we leave it undefined, the RMD may
choose not to deliver them, and the problem remains.
G.
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, August 25, 2005 7:23 PM
To: Jacques Durand
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i0019 - a formal proposal - take 2
Jacques Durand <JDurand@us.fujitsu.com> wrote on 08/25/2005 02:10:04
PM:
> When a Sequence is closed and there are messages at the RM Destination
> that are waiting for lower-numbered messages to arrive (such
as the
> case when InOrder delivery is being enforced) before they can
be
> processed by the RM Destination's application, the RM Destination
> MUST NOT deliver those messages and a SequenceClosed fault MUST
> be generated for each one.
> <JD> it is important to also say that it should not acknowledge
them either.
If we change it so that it says nothing about those messages instead,
as Anish and Chris are suggesting, would that be ok with you?
So, basically, the semantics of undelivered messages would be undefined
by
removing the above paragraph.
thanks,
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]