On 04/11/2019 5:50 pm, Robbie Gemmell wrote:
If I understand the change correctly it seems like before you would
always have got accepted after the send regardless what happens, and
the send is effectively isolated from reciept. Now, the send is tied
to reciept, and you can only reason that for multicast (assuming you
know the address is doing it) getting an accepted outcome on send
means at least one thing got it and accepted, but it could still be
the case that most recipients have either explicitly not accepted it,
dropped after receiving it, or have missed it entirely due to
occurrence of momentary disconnect between routers.
Reliable multicast - where an identified set of receivers each have an
at-least-once guarantee - is only possible with some form of
store-and-forward semantic, which the router deliberately does not
provide itself.
If what is required is something like a broker's durable subscriptions,
the router's multicast distribution is not the right tool.
Whilst I'd agree that is in some ways more consistent with the
non-multicast message routing, that you know at least something has
accepted, I think it in some ways its also unwisely implies more of a
general assurance around delivery than there actually is given it
still doesnt preclude most recipients having not seen it at all or
having not accepted it.
I would argue, given the above limits of the multicast distribution, the
accepted outcome can always be misinterpreted as implying a stronger (or
different) delivery guarantee than is actually possible. I think the
solution there is to keep improving the documentation to clarify aspects
as we realise they need clarifying.
https://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
Clients releasing or modifying a received
message could also variably result in it being resent or not by the
sender based on whether or not a single other consumer had accepted it
or not.
Related, it seems like even if all but one recipient accepts, if the
last rejects then the sender gets a reject. Again, in some ways its
good that you can know anything rejected if you want, but in others
seems poor that it signals reject at the sender while overlooking
everything else having accepted.
Given the limitations of the outcomes as defined in the AMQP 1.0
specification, there is no perfect mapping from multiple outcomes to a
single outcome. I think the simpler we can make the rules, the better.
A fundamental design characteristic of the router is end-to-end
acknowledgement.
If you get a reject, you know that the message it refers to was
delivered to at least one consumer and at least one consumer explicitly
rejected it.
If you get an accept, you again know that the message it refers to was
delivered to at least one consumer which accepted it, and that no
consumer rejected it.
To me that seems a reasonable compromise for preserving some degree of
end-to-end acknowledgement capability for the multicast distribution.
[...]
this thread is really about the router 'consuming messages to
multicast' (from a broker), which is fairly different than a producer
'sending messages to a multicast address' even if the protocol
transfer frames are the same, and it sounds like the router behaves
differently in that case which I think is perfectly reasonably.
I don't think the router does behave differently in these cases, does
it? (It certainly shouldn't). The issue is that the broker handles the
release by resending the message which other types of sender might not do).
[...]
To be clear, the main thing I think is 'wrong' is changing the
multicast behaviour 'for senders' significantly by default in a minor
release, without giving any way to do the long standing prior
behaviour.
The behaviour already has changed significantly on more than one
occasion between releases. Earlier in the thread, the original issue on
which the thread began was reported to be caused by the fix for
DISPATCH-1012, which was itself a change in semantics for all message
routed addresses (anycast as well as multicast).
I think it is better that we determine what we think the 'right'
behaviour is, and make it so. Where there are clear and concrete
requirements for backward compatible (not identical) behaviour, let's
understand those and figure out options.
With regard to the minor version, generally the expectation for qpid
dispatch is that bugs etc are fixed on the latest version. So even if
the major version was bumped for changes in semantics, that wouldn't
imply a commitment to continued fixes for older major versions. To pick
up fixes you would still need to go to the latest. Generally we try
really hard not to break things, but sometimes existing behaviour is
deemed incorrect and other times subtle differences slip through without
being fully appreciated at the time.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
