camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabrice Delaporte (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1930) Synchronized access to XPathExpression resulting in contention for multiple consumers
Date Mon, 12 Oct 2009 16:07:53 GMT

    [ 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.


Mime
View raw message