On Wed, Oct 30, 2019 at 9:54 AM 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 Just FYI, DISPATCH-1266 introduced a minor regression which has been addressed in DISPATCH-1423 whose commit message reads - "DISPATCH-1423: restore original mcast credit replenish behavior Prior to DISPATCH-1266 credit was issued for multicast senders unconditionally. DISPATCH-1266 changed this to only grant credit when subscribers were present. This broke DISPATCH-779. This patch fixes this by issuing credit on multicast links regardless of the presence of subscribers. Note well that unsettled mcast messages that are successfully forwarded do not have their credit replenished until after the receivers settle the message." Unfortunately DISPATCH-1423 did not make it into the 1.9.0 release. It will be included in the upcoming 1.10.0 release. > > 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 >
