[
https://issues.apache.org/activemq/browse/CAMEL-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=54488#action_54488
]
Fabrice Delaporte commented on CAMEL-1930:
------------------------------------------
Well, I guess this time you'll have to wait a little bit more for my next reply
:-)
I'll try to test that in the coming days.
As a side note, my personal experience with contention was also with simple
XML/XPath, but at high concurrency (100 consumers or so). I was doing some
profiling and noticed threads that were blocked on object monitors, so I
started investigating and ended up on these XPath synchronized blocks.
I'll bet back to you as soon as I can.
> 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
>
>
> 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.
