I just checked the code, for the dynamicRouter the endpoint is cached, but the 
producer is not cached.
Please feel free to create a JIRA about it.
BTW, I want to know the difference between the RabbitMQ connection and channel 
to decide if we need to create channel per producer.


--  
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 3:45 PM, Mayank Mishra wrote:

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


Reply via email to