Title: Message
I'll
try and state what was worrying me about this on the call last
night:
Although the concept "make available to the
application/user" can usefully be used to specify the meaning of a sequence,
that doesn't imply that it will necessarily happen synchronously to the
communication. Perhaps best explained by scenario:
an RM
receiver receives incoming work overnight and delivers items when they are asked
for by the human-driven application during the day. If messages arrive as part
of a sequence, the software will only offer them to the user in the right order.
It therefore fulfils the sequence requirement of making them available in order,
but the time of making available is invariably while the RMP is out of
communication with the sender.
Now
you can try and get round that by claiming that the storage of the message in
the queue in circumstances that would permit its later delivery (i.e. all prior
msgs received) is the point of "making it available to the user", but that is
distinctly artificial and confusing. If you don't bend the rules like that, then
the proposed change would mean that *none* of the messages received during any
connection session (even if they weren't part of sequences) could be ack'ed
until the next night.
But
the phrase used often last night was that the ack should be sent when the
receiver can assure the sender that the receiver now has responsibility for the
message, and the sender is absolved of its responsibility. But that can occur on
a message-by-message basis and has nothing to do with whether the message is yet
delivered or deliverable to the user.
Actually, I think the fix to the original problem here
is to understand Ack correctly at the sender side - it's just a RM ack, and
means the responsibility has been transferred. There is the possibility of
another acknowlegement - the message has been delivered, but that's at a higher
level - and may itself be sent back queued.
Peter
------------------------------------------
Peter
Furniss
Chief Scientist, Choreology Ltd
Cohesions 1.0
(TM)
Business transaction management software for application
coordination
web: http://www.choreology.com
email:
phone: +44 870 739 0066 <-- new,
from 4 August 2003
mobile: +44 7951 536168
-----Original Message-----
From: Jacques Durand
[mailto:]
Sent: 18 November 2003
22:10
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.
