On Wed, Nov 6, 2019 at 9:04 AM Ken Giusti <kgiu...@redhat.com> wrote:
> 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 > With 1.10.0 coming up in a couple of weeks which will have the above fix, Is a 1.9.1 necessary ? > > 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 <g...@redhat.com> 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: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > -- > -K >
