On Mon, 4 Nov 2019 at 19:47, Gordon Sim <[email protected]> wrote: > > 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. >
I appreciate that, my point was essentially that its still not reliable-multicast, but with the change acts a little more reliable, but at expense of not being able to get the old behaviour. However, per the bits later in the same mail, at the time I wrote that I still thought the routers prior behaviour was to always accept (given that was stated on this thread, and believing it also said on some JIRAs relating to this change being made, e.g https://issues.apache.org/jira/browse/DISPATCH-1423?focusedCommentId=16943791&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16943791) when actually per this threads existence the router could in fact release multicast messages in cases previously and so did not always accept (at least on 1.5.0, maybe 1.8.0 was different?). So the behaviour change it seems isnt quite what I thought it was. > > 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 > I think always-accepting would be fairly consistent multicast / topic like behaviour that neednt imply any consumer delivery guarantee, the same way it doesnt for brokered cases, with it only meaning that a router saw the message, particularly if covered by the documentation. Again though, per above that bit was written when I believed the router actually always accepted before, which it seems it didnt. > > 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. > I dont think we have made it simpler but I also dont think its complicated, though still open to misunderstanding. That bit was also written when I thought the router only accepted before. > 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. > Yep. As I've said, I was never against the new behaviour existing, there are clearly cases its a better fit. I only thought it was a bad idea to change it in the way [I thought it] had been, without catering to the prior behaviour at all. However, the prior behaviour I thought/asked/was-told/read existed didnt actually match what the router did, at least for 1.5.0 per this thread, and so it seems the change isnt quite as severe as I thought it was, though its still substiantially different enough from before I probably wouldnt have done it by default without option otherwise. > [...] > > 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). > I was still coming to the realisation it could release multicast messages previously, despite seemingly being confirmed otherwise that it always accepted. Maybe I was still misinterpretting. Or maybe it did behave differently in the situations. Perhaps 1.5.0 as used here and 1.8.0 did different things before it changed for 1.9.0. I'm no longer certain of much on this thread hehe, and clearly I'm in the minority view on the changes, so with that coupling I'll be shutting up shortly anyhow :) > [...] > > 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. > I wasn't suggesting otherwise around what releases are maintained or that folks are required to upgrade to for fixes and current releases (certainly they dont do that as much as we might want anyway). Just the timing and approach of the change. We've previously held making trivial changes like dropping old config names (e.g that had been replaced, or just deprecated) until the major version bump, changes that could be inconvenient at the server side but at least immediately visible to an upgrading user and cant go unseen in the slightest. Here, it seemed we significantly changed some delivery behaviour in a way that can affect application usage and actually might not be spotted immediately, and dropped it in a minor release with no way to restore the existing behaviour. Again though, given the old behaviour seemingly isnt what I thought it was, the change isnt quite as severe as I originally thought it was either. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
