> 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. * 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. 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]
