Title: Rel 33: some thoughts and proposal...
I
forgot to say: this is joint proposal from Oracle and
Fujitsu....
(the
"We" meant both)
Jacques
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: Tuesday, November 18, 2003
2:10 PM
To: ''
Subject: [wsrm]
Rel 33: some thoughts and proposal...
All:
Sorry for a late notification, but here is a
proposal for Rel 33 where a change in
the current semantics for Acknowledgements is proposed.
This is in the light of other issues
that we are currently trying to solve these days.
We would appreciate having at least the
opportunity to present it to the TC at this meeting, if enough time...
Again, apologies for late notice but
that is a very recent conclusion of ours,
and we'd like at least to get early feedback if
possible.
Jacques
-----------------------------------------------------------------
We'd like to propose a change in the
semantics of sending an Acknowledgment.
Instead
of sending the Ack when the message is received, the Ack. would be
sent
when the message is made available to the
server-side application/user.
After some discussion related
to faults/notifications, we believe this would help
significantly to get both Sender/Receiver aligned,
and also
reduce the need for additional faults and notifications, always
problematic
(e.g. if polling needed).
The
advantages we see with the new proposal are:
- More
consistent semantically because the message is made available to
the user
once acked, no more when buffered.
- Solves
the async. failure notification problems.
- Makes
Rel 50, Rel 52, and Rel 57 simpler.
- the
main difference is for ordered groups, for pending out-of-order
sequence.
- all semantics of RM features (guaranteed
delivery, dup elim, ordering) would now be
about
conditions of delivery to application.
We have considered cases where
Acks of received messages would be delayed
due to
out-of-order sequences (not made available to app yet).
To jot
some memories back, this was decision we made at the first F2F
at
Redwood Shores and was reverted back later as it may have payload
affect
during retries. We believe this is a performance issue and
a
trade-off on a functional behavior for a performance one.
Performance can be handled without problem (see below)
-------- detail:
For implementations that are concerned about
performance hit, an optimization
they
could use is to only retry the lowest un-acked message in a
grouped
ordered case, i.e., if msgs. 1,2,3 are sent and
Sender hasn't received
acks. for 2 and 3, the Sender should not retry 3
until they get an ack. for 2.
For RMP
impl. that doesn't worry about retries throttling the Receiver,
they
might still send parallel retries. Either approach won't have any
effect
on the end user behavior.
