On Thu, Oct 31, 2019 at 1:31 PM Ted Ross <tr...@redhat.com> wrote: > > > On Thu, Oct 31, 2019 at 6:57 AM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > >> 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 > > > Yes. > > >> ....but in the latter case, now it would release >> it instead? > > > Yes. > > >> If so, is it possible to configure the old behaviour, for >> folks that actually wanted that? >> > > Perhaps. Does anyone want it? It _would_ prevent the looping behavior. >
Actually, I think the choice that we would consider making configurable would be: Release all multicast deliveries for which there is no consumer (the present behavior); or Withhold credit for sender links on multicast addresses for which there is no consumer. The accept-and-possibly-drop is not, in my opinion, a desirable behavior. If someone wants that behavior, they would be better off sending their deliveries pre-settled. > > >> >> 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? > > > If there are different dispositions, there is a priority list that > determines which of the provided dispositions will be returned to the > sender. > > >> What if one recipient doesnt provide an outcome for ages? > > > Then that delivery will not be settled for ages. > > >> Or >> goes away without providing one? >> > > Then the outcome from that recipient will be MODIFIED at the time the > receiver detaches. > > >> >> 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 >> >>
