Thanks Willem, I think creating channel per request is not a problem, but creating is connection for each request will be a problem.
Do we require to create a producer each time if we encounter endpoint (having same identifier) declaration. If this is the expected behavior then yes we can have caching for connection in the producer. Can I create a JIRA for this? With regards, Mayank On Thursday 07 November 2013 01:05 PM, Willem jiang wrote:
I just checked the code of RabbitMQProducer, it create new connection and channel when creating the producer. I think we need to cache the connection or channel to avoid creating a new connection per new Producer. In you case if there is no much of RabbitMQ Endpoint, you can setup the route like this to avoid creating producer dynamically. from(“direct:queue1”).to("rabbitmq://xxx.xxx.xxx.xxx (http://xxx.xxx.xxx.xxx):queue1") from(“direct:queue2”).to("rabbitmq://xxx.xxx.xxx.xxx (http://xxx.xxx.xxx.xxx):queue2”) The you can set up dynamic slip endpoint uri as “direct:queue1”, “direct:queue2” -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Thursday, November 7, 2013 at 2:27 PM, Mayank Mishra wrote:Hi all, We are using Camel RabbitMQ component (v2.12.0) to publish message on RabbitMQ. We are using dynamic slip router to publish the messages to the endpoint (like, rabbitmq://xxx.xxx.xxx.xxx (http://xxx.xxx.xxx.xxx):xxxx/<exchange>) something like below, .dynamicRouter(method(ServiceRouter.class, "slip")) As the message are getting published we saw heavy increase in the number of open FDs on RabbitMQ admin. Looking into the code, it seems with each time a producer will be created (overridden DefaultEndpoint's createProducer() method) a new connection to RabbitMQ will get created, which is going to increase FDs. Please let me know if there is some other way of doing above or there is a bug with the component. With regards, Mayank ________________________________ NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.
________________________________ NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.
