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