Re: Thread issue with RabbitMQ component
We are using Came version 2.20.1. Its not that uncommon to use Reply/Response when you are tying to bridge Sync with Aysnc calls may be I’m wrong. I had searched through RabbitMQ Java Client documents, which is used underneath Camel-RabbitMQ component. They prescribe few optimisation techniques and best practices (read else where) link for brevity https://www.rabbitmq.com/direct-reply-to.html <https://www.rabbitmq.com/tutorials/tutorial-six-python.html>.
I would like to help fix this if possible, but I’m lost in terms of where to start. As I’m using this component as part of the multicast and not sure where reply-to attribute is added i.e. as part of multicast code or in rabbitmq component.
> On 3 Jul 2018, at 11:47, Claus Ibsen <claus.ibsen@xxxxxxxxx> wrote:
> What version of Camel do you use?
> And are you always using temporary "private" dynamic queues for request/reply schenarious? Isnt there an overhead of some sorts on rabbitmq side if you need to have a new queue per message?
> Well regardless if that is a common practice, we can look into a way of configuring camel-rabbitmq to allow to stop the reply listener when a message is received or something.
> On Mon, Jul 2, 2018 at 1:10 PM, Nataraj Basappa <n5j.b5a@xxxxxxxxx <mailto:n5j.b5a@xxxxxxxxx>> wrote:
> Hi All,
> I’m relatively new to Camel and RabbitMQ and seeing issue similar to the one reported here - http://camel.465427.n5.nabble.com/Apache-Camel-RabbitMQ-consumers-leaves-back-extra-threads-running-tt5804994.html <http://camel.465427.n5.nabble.com/Apache-Camel-RabbitMQ-consumers-leaves-back-extra-threads-running-tt5804994.html>
> We have spring boot application that uses RabbitMQ in Request/Response mode through Camel RabbitMQ Component. Functionally application works as expected but the issue is the threads that are being created for every request. Number of connections and hanging RabbitMQ Consumer increases every-time a request passes through RabbitMQ component. I started to use the connectionFactory with assumption that connection pooling would with executor service would decrease the threads but that seems not to have much benefit.
> Is there anything else I should be looking at to iron out the issue? Attached is a screenshot and one obvious thing that pops out is there is always connection pair one for IPV4 and other for IPV6.
> Second issue I think is that consumer (dynamic reply queue) hangs around and hogs the thread. Not sure how to close it as the dynamic queues are created as part of Request/Response called from Camel multicast.
> Nataraj Basappa
> Claus Ibsen
> http://davsclaus.com <http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 <https://www.manning.com/ibsen2>