I dont recall any mention of that element changing, so its presumably whatever 1.9.0 does currently? Thats documented at: http://qpid.apache.org/releases/qpid-dispatch-1.9.0/user-guide/index.html#message_settlement_and_reliability
I've raised https://issues.apache.org/jira/browse/DISPATCH-1479 for some related doc improvement suggestions in that area. Robbie On Tue, 12 Nov 2019 at 08:22, VERMEULEN Olivier <olivier.vermeu...@murex.com> wrote: > > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
