Re: Thread issue with RabbitMQ component

[Claus Ibsen]

Hi

Ah okay, the direct reply-to seems like an optimised and special
feature of rabbitmq. I do not think we have that supported at this
moment in camel-rabbitmq.
You are welcome to log a JIRA ticket



On Wed, Jul 4, 2018 at 10:24 AM, Nataraj Basappa  wrote:
> Hi,
> 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 
> .
>
> 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.
> —
> Regards,
> Nataraj Basappa
>
>> On 3 Jul 2018, at 11:47, Claus Ibsen  wrote:
>>
>> Hi
>>
>> 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 > > 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
>>  
>> 
>> 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.
>> —
>> Regards,
>> Nataraj Basappa
>>
>>
>>
>> --
>> Claus Ibsen
>> -
>> http://davsclaus.com  @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2 
>> 



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Thread issue with RabbitMQ component

[Nataraj Basappa]

Hi,
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 
.

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.
—
Regards,
Nataraj Basappa

> On 3 Jul 2018, at 11:47, Claus Ibsen  wrote:
> 
> Hi 
> 
> 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  > 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
>  
> 
> 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.
> —
> Regards,
> Nataraj Basappa
> 
> 
> 
> -- 
> Claus Ibsen
> -
> http://davsclaus.com  @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2 
> 

Re: Thread issue with RabbitMQ component

[Claus Ibsen]

Hi

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  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
> 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.
> —
> Regards,
> Nataraj Basappa
>



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Thread issue with RabbitMQ component

[Nataraj Basappa]

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
 

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.
—
Regards,
Nataraj Basappa