With the below, are you saying that previously the router would always immediately accept an unsettled message sent to a multicast address, and then either send it on (pre-settled) or drop it if there was nowhere to direct it....but in the latter case, now it would release it instead? If so, is it possible to configure the old behaviour, for folks that actually wanted that?
Or does it still accept in that case and you just meant that the end receiver outcomes are now interpreted to decide the response to the sender? What if the different multicast points return different outcomes? What if one recipient doesnt provide an outcome for ages? Or goes away without providing one? Or maybe it was both of the above? :) In some ways either of these seem like odd changes for a minor release unless its possible to toggle the previous long standing behaviour, and not say have to switch all your senders to pre-settled to mimmick but still not quite match it (since at least with the unsettled case before, youd at least know whether a [first, if multiple hops] router processed the message at all). Robbie On Wed, 30 Oct 2019 at 13:54, Ken Giusti <kgiu...@redhat.com> wrote: > > On Tue, Oct 29, 2019 at 6:23 PM VERMEULEN Olivier < > olivier.vermeu...@murex.com> wrote: > > > Hello, > > > > Yes the waypoint address (in from broker) is using a multicast > > distribution. > > Unfortunately skipping the broker is not an option for us right now. > > Our whole architecture relies on the broker to guarantee that no messages > > will ever be lost... > > > > That won't be the case for multicast actually. Prior to release 1.9.0 of > the router multicast messages would be dropped without notification when > under load. > > This relates to the issue you're experiencing now I believe. In 1.9.0 we > fixed this via > > https://issues.apache.org/jira/browse/DISPATCH-1266 > > Previously multicast messages were marked a pre-settled on entry to the > router and an "accepted" status was returned to the sender _before_ the > multicast was forwarded at all. Since the message was marked pre-settled > the router mesh will be more likely to drop it should congestion occur. > (Note this not the case with unsettled anycast messages - the router will > send a "release" status should the message need be discarded). > > This auto-settle behavior was undesirable for a number of reasons as you > can imagine, so in 1.9.0 we changed the behavior of multicast deliveries: > > *unsettled* messages sent to multicast addresses are no longer pre-settled > by the router. The router will send back the final acknowledgement > (accepted, release, etc) once all *present* subscribers for the multicast > address return acknowledgements. > > The behavior of pre-settled multicast did not change. > > So you can probably restore the original behavior by reverted back to a > pre-1.9.0 release, however be aware that even then there's no guarantee the > message will be dropped. In fact it's _more_ likely to be dropped (and > signalled as accepted) in pre-1.9.0 releases. > > > > > For information we're asking for a quick workaround because we're facing > > this problem on a client production environment... > > > > Thanks, > > Olivier > > > > -----Original Message----- > > From: Ken Giusti <kgiu...@redhat.com> > > Sent: mardi 29 octobre 2019 18:07 > > To: users <users@qpid.apache.org> > > Subject: Re: multicast without consumers > > > > On Tue, Oct 29, 2019 at 11:54 AM jeremy <jeremyao...@gmail.com> wrote: > > > > > Hello Gordon, > > > > > > We debugged the dispatch router, and fell on the code which releases > > > undeliverable messages( > > > https://github.com/apache/qpid-dispatch/blob/1.5.0/src/router_core/tra > > > nsfer.c#L869 > > > ). > > > > > > Check the comment on line 879. It states that if the distribution is > > > multicast, the credit will be replenished after the release. The issue > > > that introduced this behavior is: > > > https://issues.apache.org/jira/browse/DISPATCH-1012 > > > > > > > > Is the waypoint address (in from broker) using multicast distribution? > > > > The router treats multicast addresses like topics - you can publish to a > > multicast address (topic) regardless of the presence of consumers. That's > > the reason credit is being replenished even when no consumers are present. > > > > That's probably what's happening here - broker sends first queued message > > to the router, which attempts to send it to the topic. Since there are no > > consumers (and the message is sent from the broker as unsettled) the > > router cannot deliver it so it returns the released status. The released > > status causes the broker to redeliver the message. Repeat. > > > > > > > > > > > In fact, we need an urgent fix/workaround for this. Perhaps there is a > > > quick workaround, awaiting the full analysis of this problem? > > > > > > > > As a work around can you avoid sending these multicast messages to the > > broker queue? In other words send them directly to the router instead of > > using a waypoint? > > > > > > > > > Thanks > > > > > > > > > > > > > > > ----- > > > Cheers, > > > Jeremy > > > -- > > > Sent from: > > > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > > > > > --------------------------------------------------------------------- > > > 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. > > > > > -- > -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
