You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Christian Schneider <ch...@die-schneider.net> on 2012/08/01 22:33:14 UTC
Re: New JMS connection being created for every message
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.
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
Re: New JMS connection being created for every message
Posted by Claus Ibsen <cl...@gmail.com>.
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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen