On Tue, Nov 12, 2019 at 6:55 AM Robbie Gemmell <[email protected]> wrote:
> 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 > > Thanks Robbie - that is the correct documentation and applies to router 1.9.0+ multicast. The AMQP 1.0 standard does not provide any guidance regarding multicast. As far as I'm aware, the concept of a multicast/broadcast messaging pattern is not defined at all by the core 1.0 spec. Which means that there's no recommended course of action given multiple different terminal outcomes arriving for a single multicast transmit. This means the router has to establish a behavior that "makes sense" when a publisher to a multicast address wants an explicit terminal outcome. >From the standard the terminal outcome signals to the sender the status of the message delivery at the consumer. The outcomes can signal whether the receiver accepted the message, rejected it due to error, release it for re-delivery, etc. In the case of multiple different returned terminal outcomes (possible with multicast), the router has implemented a priority scheme for determining the "best" single outcome to return to the sender. This is the priority scheme used by the router as implemented in DISPATCH-1266 <https://issues.apache.org/jira/browse/DISPATCH-1266> in 1.9.0+: REJECTED: since REJECTED is a hard error (the message is unprocessable) it is considered a failure and should not be filtered out as this could cause important issues to be hidden. Therefore it is the highest priority and will be returned to the sender regardless of other non-REJECTED outcomes. If the sender receives a REJECTED outcome it can assume: 1) at least one consumer received the message, and 2) the message is in error. ACCEPTED: if no receivers REJECT the message, the next highest priority is ACCEPTED. If the sender receives an ACCEPTED outcome it can assume that at least one consumer has received the message. MODIFIED: if no receivers REJECT or ACCEPT the message, but one or more forwarding failures occur and the message delivery is in doubt the router will return MODIFIED. If the sender receives a MODIFIED outcome that indicates that the router is unable to determine whether or not the message was forwarded to at least one consumer (e.g. connection drop occurs before outcome is known). RELEASED: lowest priority - if the sender receives a RELEASED outcome it can be guaranteed that the message was not delivered to any consumer (and may be safely re-sent without fear of duplication). This behavior is as consistent as possible with the terminal outcome for anycast links. > 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 > <[email protected]> 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 <[email protected]> > > Sent: jeudi 7 novembre 2019 17:11 > > To: users <[email protected]> > > Subject: Re: multicast without consumers > > > > On Thu, Nov 7, 2019 at 9:58 AM Chuck Rolke <[email protected]> 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 <[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 > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] For > > > additional commands, e-mail: [email protected] > > > > > > > > > > -- > > -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: [email protected] > For additional commands, e-mail: [email protected] > > -- -K
