Please excuse the top-posting - we're planning the next release of qdrouterd and I'd like to confirm what the plan forward is regarding credit management for multicast links.
After reading through this discussion I believe the general consensus is to ensure all non-anonymous links use the same link credit semantics regardless of the type of address of the link. Specifically: multicast link credit semantics will be the same as anycast - block credit until consumers are present. Now with respect to those users that expect to be able to send multicast messages regardless of consumers (the behavior that was introduced in DISPATCH-779 <https://issues.apache.org/jira/browse/DISPATCH-779>): The qdrouterd has always supported unconditional credit allocation on ANONYMOUS links. In other words, anonymous links will receive linkCapacity credit regardless of the presence of consumers (since there's no address to block on). I would argue that DISPATCH-779 is in fact not-a-bug - the correct solution was to use an ANONYMOUS link instead of an addressed link. In summary: 1) All non-anonymous producer links will only be granted credit when the router is aware of at least one consumer. This applies to all of the address treatments uniformly (multicast, anycast, balanced, closest, ...) 2) Declare the fix to DISPATCH-779 invalid and change the JIRA's state to not-a-bug with the comment explaining the need to use anonymous links for that use case. 3) Declare 1.9.0 to be Broken and backport the proposed fix and release 1.9.1 Let me know what you all think - I'm assuming silence is tacit approval of this proposal ;) On Tue, Nov 5, 2019 at 9:29 AM Gordon Sim <[email protected]> wrote: > On 05/11/2019 11:31 am, Robbie Gemmell wrote: > > 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. > > I think the brokered case is different as it involves a > store-and-forward semantic. The producer always cares only that the > broker it sent it to got it. The forwarding of the message is always > decoupled from that and so the state of consumers is irrelevant to the > acknowledgement for both queues and topics. > > The router provides an end-to-end acknowledgement rather than > store-and-forward. Though the limitations of the outcomes defined in the > AMQP specification prevent the fullest expression of that, Ken's work > allows what is in my view a more internally consistent approach. > > Reject always means that a receiver rejected it. Accept always means > that a receiver accepted it, and it was not rejected. Release always > means that either the message could not be routed to any receiver or > that any receiver to which it was routed explicitly released it. > Modified means it was routed to at least one receiver which either > explicitly issued the modified outcome or was disconnected before it > returned any explicit outcome. > > (Maybe in the future we could even have a custom outcome, support for > which could be advertised in the connection or link capabilities, that > allowed an explicit aggregation of the outcomes from each distinct > receiver to which the message was routed to be included) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K
