On Wed, Aug 1, 2012 at 10:33 PM, Christian Schneider <ch...@die-schneider.net> wrote: > Just to recap what we found today. The reason for the bad performance seems > to be that camel polls for replies in the producer with a default > of 1000ms. Setting receiveTimeout=10 on the producer seems to speed up the > route a lot. > > After we found that your colleague also found that this is actually > documented in the camel-jms documentation :-) > http://camel.apache.org/jms.html > I added the relevant section below. > > I am not really sure why the receiveTimeout really controls the polling but > it works. In any case the option name looks a bit misleading. I guess > pollingIntervall would > be more acurate. >
Its the name of the option the spring guys gave it. Use a temporary or exclusive queue for the reply message is faster, as JMS message selectors i not needed, and then the receiveTimeout doen't matter. > Christian > > ----- > > > Request-reply over JMS and using a shared fixed reply queue > > If you use a fixed reply queue when doing Request Reply > <http://camel.apache.org/request-reply.html> over JMS as shown in the > example below, then pay attention. > > from(xxx) > .inOut().to("activemq:queue:foo?replyTo=bar") > .to(yyy) > > In this example the fixed reply queue named "bar" is used. By default Camel > assumes the queue is shared when using fixed reply queues, and therefore it > uses a JMSSelector to only pickup the expected reply messages (eg based on > the JMSCorrelationID). See next section for exclusive fixed reply queues. > That means its not as fast as temporary queues. You can speedup how often > Camel will pull for reply messages using the receiveTimeout option. By > default its 1000 millis. So to make it faster you can set it to 250 millis > to pull 4 times per second as shown: > > from(xxx) > .inOut().to("activemq:queue:foo?replyTo=bar&receiveTimeout=250") > .to(yyy) > > Notice this will cause the Camel to send pull requests to the message broker > more frequent, and thus require more network traffic. > It is generally recommended to use temporary queues if possible. > > > > Am 30.04.2012 15:52, schrieb weberj: > >> No, the resource adapter is fine. I wrote a simple MDB that uses the RA >> and >> just echoes back a message to the reply Q. In the onMessage() call I >> create >> and close the connection. This MDB can handle 20 messages/s, whereas Camel >> handles only one. >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/New-JMS-connection-being-created-for-every-message-tp5637735p5676000.html >> Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
