Yes, I was suggesting potential for improvement around that aspect. If you care about the [network] performance though, the simpler suggestion is just to not operate your consumer in such fashion (receive 1 msg, close) if possible and so avoid the situation, which I believe only happens when the final consumer closes, and even then only when there isnt a sufficient enough message backlog to use the routers provided credit.
Robbie On Mon, 2 Dec 2019 at 08:41, VERMEULEN Olivier <olivier.vermeu...@murex.com> wrote: > > Hello, > > Thanks for the analysis. > And sorry I actually forgot to mention what we were expecting here. > We know about the dispatch-router 250 pre-fetch and we're very much counting > on that for performance. > What we were not expecting are the 2 round-trips of the 9 remaining messages > between the broker and the dispatch-router. > Robbie you were talking about a way to improve that? That would be nice to > avoid unnecessary network traffic and potential performance loss... > > Thanks, > Olivier > > -----Original Message----- > From: Gordon Sim <g...@redhat.com> > Sent: vendredi 29 novembre 2019 18:05 > To: users@qpid.apache.org > Subject: Re: High number of transfers between Broker-J and Dispatch-Router > > On 29/11/2019 4:51 pm, Robbie Gemmell wrote: > > On Fri, 29 Nov 2019 at 16:21, Gordon Sim <g...@redhat.com> wrote: > >> In the trace you included it seems there are 19 transfers from broker > >> to router (the last 9 get resent once before the credit is drained). > >> > > > > I see 28 transfers from broker to router. > > Yes, sorry, I miscounted. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org > > ******************************* > 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
