On Mon, 4 Nov 2019 at 15:08, Gordon Sim <[email protected]> wrote: > > In my opinion, in the context of the router, the accepted outcome should > always mean that the message was routed to an appropriate receiver which > then accepted it. > > If a producer, connected to router A sends messages on address for which > there is a consumer connected to router B, then if router A and router B > become momentarily disconnected, those messages that could not be routed > will be released and the producer knows that they did not make it to the > intended recipient. Having the same behaviour by default for multicast > makes sense in my opinion as it is more consistent.
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. 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. 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. > > The behaviour of releasing messages due to there being no consumer to > which they can be routed, yet still reissuing credit for them, is in my > opinion an inconsistent combination. Either the router cares about > whether it can route on that address (in which case it will release any > messages that can't be routed and will not grant more credit) or it does > not (and could therefore 'accept' message though it immediately drops > them, but always issue credit). > I agree that its inconsistent to issue credit and then release, I just think that shouldn't be releasing by default....ahh <insert realisation of misunderstanding and stupidity here>. I have mostly been discussing the perspective of a producer, sending messages to the router and it then sending on to recipients, e.g I asked for clarity on some points on that which Ted addressed here https://lists.apache.org/thread.html/1e14ca7d111d4ea7e60a483ae9c48d953590284a87e291094c518792@%3Cusers.qpid.apache.org%3E However, considering this thread again, it seems that based on that I have been operating on a misunderstanding that the router was prevously always accepting messages arriving for multicast before and now isnt, when that clearly isnt the case or this thread simply wouldnt exist (another about dropped messages presumably would) since it is ultimately about Dispatch 1.5.0 releasing messages for multicast at a waypoint. Alas, 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 dont think it is unreasonable for the router to be releasing messages it has 'consumed to multicast' if there is nowhere to send them. As you've said, continuing to grant new credit in this scenario could also be seen as inconsistent, and not granting there wouldnt necessarily be unreasonable, it depends what folks want in a given case. Its again somewhat different than the case of something sending to a multicast address. > Personally I would be inclined to treat DISPATCH-1423 and DISPATCH-779 > as not-a-bug. I understand that the router behaviour might not always be > what everyone expects (particularly those thinking in terms of a 'topic' > on a 'broker'), but I don't think it is 'wrong'. 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. I think the new behaviour is perfectly reasonable in general and especially for those that want it, and havent been depending on the prior behaviour that existed until now (related note: do people have to upgrade all their routers at once with such dispirate router behaviour, or will it still 'just work' albeit completely differently depending on the router in use?) Its also clear I've been arguing around a slightly different use case than was actually really being discussed for this thread however, coupling it with misunderstanding of the old behaviour that doesnt reflect reality (i.e the router could previously release messages meant for multicast before, for a waypoint). >I'm not yet convinced > there is a sufficiently strong case for needing that behaviour to > justify an extra configuration option to test and document. > > > --------------------------------------------------------------------- > 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]
