Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 60500DF5F for ; Mon, 16 Jul 2012 20:05:02 +0000 (UTC) Received: (qmail 79239 invoked by uid 500); 16 Jul 2012 20:05:02 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 79208 invoked by uid 500); 16 Jul 2012 20:05:02 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 79200 invoked by uid 99); 16 Jul 2012 20:05:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jul 2012 20:05:02 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com designates 209.85.217.173 as permitted sender) Received: from [209.85.217.173] (HELO mail-lb0-f173.google.com) (209.85.217.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Jul 2012 20:04:58 +0000 Received: by lbok6 with SMTP id k6so9760914lbo.32 for ; Mon, 16 Jul 2012 13:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=LfqJB1BMFGtw4/8+1LhH8BSA3+Iz3Ergc8fzplBtv0Y=; b=Cbj1DZ8hZLuRPqHa5RHP0sWYgVGTGmqVhwQQR2sRLdhEEZvzyc2CB7cSPBDVLCHLHi 5eDjhyTqnZUJ7beGWHa2qvtPrCi0rH4fRJk+oTbc5sidxbJOnA+pRRjxMMdEoRFZPonl gIk86BIgdp30mUekNjW8COeeXBSPvHegsaqiWZu4EjGX9Tr1Yt9j2g7VBVbX5VTYrfFC hozF0G3VmFCxZWCLGuJ3Wqexv/FCwv3m6YvMTcesB+ZHHpc7sIykIPPzjxv+Lbskt/Qw H+cS4YL1utS8gXh6zY6TQzsoRD4ThfVL4wQ64Gv0fT8jBLqFS+ZBZSOo3WdrK3fkLsv1 lmNQ== Received: by 10.152.103.11 with SMTP id fs11mr12692762lab.23.1342469076421; Mon, 16 Jul 2012 13:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.49.73 with HTTP; Mon, 16 Jul 2012 13:04:16 -0700 (PDT) In-Reply-To: References: <1342320731329-5716049.post@n5.nabble.com> From: Claus Ibsen Date: Mon, 16 Jul 2012 22:04:16 +0200 Message-ID: Subject: Re: fyi - SI To: dev@camel.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jul 16, 2012 at 7:24 PM, Christian M=FCller wrote: > Great explanation Claus. I answered in the SI forum to make this clear fo= r > 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=3Dfalse) 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 ${body} To just transform the reply to the incoming message. > Best, > Christian > > On Mon, Jul 16, 2012 at 8:03 AM, Claus Ibsen wrot= e: > >> On Mon, Jul 16, 2012 at 12:36 AM, Christian M=FCller >> 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 >> 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: cibsen@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> --=20 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