Hello, Regarding the multicast , what will be the behavior in 1.10.0 if all *present* subscribers do not return the same acknowledgment?
Thanks, Olivier -----Original Message----- From: Ken Giusti <kgiu...@redhat.com> Sent: jeudi 7 novembre 2019 17:11 To: users <users@qpid.apache.org> Subject: Re: multicast without consumers On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <cro...@redhat.com> wrote: > > 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. > > > > When vhost policy is in force then there is a problem problem with > forcing users to use anonymous links in order to send when there are > no consumers. The 'allowAnonymousSenders' policy setting then allows > the sender to send to *any* address, which is not always desirable. > > This discussion *also* needs to include the link's settlement-mode to > describe router behavior for senders using links with a named or > unnamed (anonymous) target. The send settlement modes are: > SND_SETTLED, SND_MIXED, and SND_UNSETTLED. > > As I understand it: > * A sender link in SND_MIXED or SND_UNSETTLED modes will behave as > Option 1. > Agreed. > * A sender link in SND_SETTLED mode will behave > differently: senders receive credit immediately regardless of consumer > presence; messages are settled and credit is restored at the router's > receiver so that the sender can send as fast as possible and it looks > to the sender like all messages were accepted; messages are forwarded > to receivers pre-settled; messages may be dropped aggressively due to > congestion. This is like a 'broadcast-best-effort' treatment. > > That's not my observations (against master and as far back as 1.8.0). When I attach a sender with snd-settle-mode=1 (send all presetted), no flow is granted to the sender when there are no consumers present. > Clients can choose the behavior they want by combining the link > send-settle mode (settled, mixed, unsettled) and the sender link > target (named link target or anonymous blank link target). Maybe a > table or two showing how the router treats message settlement, initial > credit grant, and per-message credit restoration both with and without > policy restrictions would be in order. > > That said, I agree with option 1. Option 2 might be satisfied with > documents that have the suggested table showing message treatments. > Option 3 is less of an issue with 1.10 coming soon. > > > 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 <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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > additional commands, e-mail: users-h...@qpid.apache.org > > -- -K ******************************* This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorized to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system.
