I made the test with WebSphere MQ 7.0.1.3 and also didn't see any problems.
It tooks 101ms to receive the response (with persistent messaging).
{code}
2011-01-26 00:37:15,344 [main ] DEBUG
Configuration$CamelJmsTemplate - Sending JMS message to: queue:///hello with
message:
JMSMessag
I made a test with the
org.apache.camel.component.jms.JmsSimpleRequestReplyTest, part of the
camel-jms unit tests. It use the broker URL
vm://localhost?broker.persistent=false.
In this test, the response was received by the JmsProducer after 59ms
(19:01:04,447 - 19:01:04,516). It looks like everyt
Marat, did solve this your performance issue? Or what do you mean?
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-JMS-InOut-Performance-Issues-with-Correlation-Mechanism-tp489714p3356692.html
Sent from the Camel Development mailing list archive at Nabble.com.
Use Camel JMS Component's configuration parameter:
useMessageIDAsCorrelationID=true
from(amq:...).inOut(jms:...?useMessageIDAsCorrelationID=true)
Marat
On Tue, Jan 25, 2011 at 11:32 AM, Christian Mueller <
christian.muel...@gmail.com> wrote:
>
> Thanks for your response Claus. I had already a
Thanks for your response Claus. I had already a look at the wiki page, but it
didn't describes our issue. My colleges have this problem with only one
reply message in the reply queue (using Camel 2.2.0 without specifying the
replyTo) with ActiveMQ and WebSphereMQ.
I will have look into the code an
Hi
See the camel-jms wiki page under section _Concurrent Consuming_ and a
bit down at _Request-reply over JMS_ how to make it speedy
On Tue, Jan 25, 2011 at 5:03 PM, Christian Mueller
wrote:
>
> Hello Olivier!
>
> My collegues report the same problem. I will have a look into it. Keep you
> pos
Hello Olivier!
My collegues report the same problem. I will have a look into it. Keep you
posted...
Cheers,
Christian
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-JMS-InOut-Performance-Issues-with-Correlation-Mechanism-tp489714p3356523.html
Sent from the Camel Devel
By the way,
Consider using a second strategy of picking up replies from a shared queue
by using replyToDestinationSelectorName property. The idea that each
producer has a unique value for a named property on which you select reply
messages on. The the reply consumer will collect all reply messages
It's been a while since I looked at this code. I would verify that your
changes will not break local transaction support. I suspect that this could
be an issue if you were to simply block the producer with a timed receive
call.
There is a bunch of tests in Camel unit tests. Are they all passing?
