On Mon, Jul 16, 2012 at 7:24 PM, Christian Müller
<christian.muel...@gmail.com> wrote:
> Great explanation Claus. I answered in the SI forum to make this clear for
> them.
>
Well you could match the examples a bit more. The SI sends directly
from the java code to a the JMS queue.
Where as in Camel its send to a direct endpoint in a Camel route, and
then to the JMS queue.
You could omit the Camel route, and send directly the the JMS queue,
like SI does.
Also disabling JMX performance stats may make a difference, but only
for really high end performance.
In this example its more the TCP / remote bandwith that is the
bottleneck, and the CPU cycles to calculate performance stats for JMX.
Also in Camel you can disable persistent on request/reply when sending
(eg replyToDeliveryPersistent=false) but SI is sending persistent as
well. But as an end user you may want this in case you are okay with
sending the msg as non persistent to the broker.
Also SI is having 10 concurrent consumers on the consumer side. Where
as Camel has 1 consumer only. But that dont matter as much as the
processing is just sending back the same message.
In Camel you send the message to a bean, without giving a method name.
Which forces Camel to instrospect the bean on the invocation. A better
solution to match SI would to use the message translator EIP
<transform><simple>${body}</simple></transform>
To just transform the reply to the incoming message.
> Best,
> Christian
>
> On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
>
>> On Mon, Jul 16, 2012 at 12:36 AM, Christian Müller
>> <christian.muel...@gmail.com> wrote:
>> > Thanks Adam for this pointer.
>> > I respond to this thread with an optimized version of the Camel route
>> which
>> > is about two times faster than the Spring integration solution.
>> >
>>
>> Btw the default request/reply with Camel JMS is using temporary
>> queues, eg do not specify a replyTo queue name. The temporary queues
>> is like exclusive, and fast.
>>
>> The shared queues are for clustered / and/or if the queue is used for
>> other purposes/other apps etc. eg in some brokers its not
>> easy/possible to create new queues on the fly etc.
>>
>> And the shared option was the default from the early days of the Camel
>> project, and we have kept the shared as default since.
>>
>> Its of course documented in the JMS page. But I guess SI people don't
>> read the docs
>> http://camel.apache.org/jms (request/reply section)
>>
>> I logged a ticket to add some logging when shared queues are in use,
>> so the end user may notice this more easier, than go read the JMS docs
>> https://issues.apache.org/jira/browse/CAMEL-5444
>>
>> > Best,
>> > Christian
>> >
>> > On Sun, Jul 15, 2012 at 4:52 AM, aedwards <a...@middleware360.com>
>> wrote:
>> >
>> >>
>> >>
>> http://forum.springsource.org/showthread.php?128152-Spring-Integration-2-1-request-reply-benchmark-tests-showed-very-poor-performance
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >> http://camel.465427.n5.nabble.com/fyi-SI-tp5716049.html
>> >> Sent from the Camel Development mailing list archive at Nabble.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
>>
--
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
