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
