Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1083316494.1255363673580.JavaMail.jira@brutus>
Date: Mon, 12 Oct 2009 09:07:53 -0700 (PDT)
From: "Fabrice Delaporte (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Commented: (CAMEL-1930) Synchronized access to
 XPathExpression resulting in contention for multiple consumers
In-Reply-To: <2080826390.1251105350107.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/CAMEL-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54718#action_54718 ] 

Fabrice Delaporte commented on CAMEL-1930:
------------------------------------------

Hi Claus,

Sorry for the delay, been quite busy these days but finally got some time to run some tests against your patch.

Attached is my own version (heavily inspired by your own test case). By the way, why are you using an Executor to send your message to the SEDA queue ? Being an asynchronous endpoint I'm not sure I see the point in using a thread pool.

Anyway, I'm sending 100 000 xml messages (a little bit bigger than yours) to the seda queue, and then awaits for the mock endpoints to reach their expected message count to measure actual processing time. The XPath expression is also closer from what we may have here in production (kind of a big switch on the message type, there may be more efficient ways to do that (especially get rid of the // wild card to put a true /message/messagetype) but that's not the point here, the point is that we get something heavier on the CPU side. And, actually, setting a low value for consumer count does not prevent contention from happening (10 in my test case).

Results are pretty cool. On my computer it gives on average :
- around 150s without your patch
- around 110s with the patch

That's about 36% faster, so I think it's worth including the patch, although I have to admit that the performance difference is smaller than what I had expected (I guess that the more cores you have, the bigger the difference).

In addition to that I also attached two screenshots of my instance of JVisualVM to show contention without the patch (red threads) and with the patch (yeah, that green is beautiful).

Cheers,
Fabrice


> Synchronized access to XPathExpression resulting in contention for multiple consumers
> -------------------------------------------------------------------------------------
>
>                 Key: CAMEL-1930
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1930
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.0-M3
>         Environment: Java 1.6, Spring 2.5.6
>            Reporter: Fabrice Delaporte
>            Assignee: Claus Ibsen
>             Fix For: 2.1.0
>
>         Attachments: camel_1930.patch, with-contention.jpg, without-contention.jpg, XPathRouteConcurrentBigTest.java
>
>
> Hi,
> I'm using Camel to do some JMS message routing. Messages are XML so xpath is a natural choice.
> However when using a choice with an xpath expression, the XPathBuilder creates one XPathExpression object. According to the specification, these objects are not thread safe so synchronizing looks natural. But then, using multiple jms consumers is totally useless since no concurrent evaluations can be made.
> XPathExpression objects would rather need to be stored in a ThreadLocal to avoid synchronization and contention.
> Cheers,
> Fabrice

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.