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 <[email protected]> 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 <[email protected]> > Sent: vendredi 29 novembre 2019 18:05 > To: [email protected] > 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 <[email protected]> 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: [email protected] For additional > commands, e-mail: [email protected] > > ******************************* > 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
