On Wed, Nov 6, 2019 at 10:05 AM Ganesh Murthy <gmur...@redhat.com> wrote:
> 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 ? > > I really don't feel strongly about #3 or #2 quite frankly. What I *do* care about is #1. What we do regarding release(s)/backporting really depends on whether or not we do #1, so let's postpone the #3 and #2 discussion until we decide if #1 merits inclusion in next release. > > > > 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 > > > -- -K
