[
https://issues.apache.org/jira/browse/CAMEL-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087133#comment-13087133
]
Ben Manes commented on CAMEL-4345:
----------------------------------
Please open an issue to OSGi-ify CLHM and I'll do it for the next release (no
timeframe).
As Google Guava is OSGi ready and I helped port the algorithm into MapMaker,
that may also be a reasonable choice if it becomes a concern.
I'll be meeting up with Doug Lea in Sept. to discuss caching for JDK8, so maybe
we'll see something in the standard libs eventually.
Cheers,
Ben
(CLHM author, Googler)
P.S. Don't you love Google Alerts? ;)
> Synchronized code causes long delays and hangs for big applications
> especially with Blueprint
> ---------------------------------------------------------------------------------------------
>
> Key: CAMEL-4345
> URL: https://issues.apache.org/jira/browse/CAMEL-4345
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.8.0
> Environment: Linux and Mac multicore machines
> Reporter: Jeff Genender
> Attachments: CAMEL-4345.patch
>
>
> The DefaultCamelContext uses synchronized "endpoints" which ends up
> ultimately extending a LinkedHashMap through the LRUCache. The LinkedHashMap
> is obviously not thread safe, so it requires synchronized guards when
> accessing the endpoints object. This especially happens in the
> getEndpoint(s) calls in the DefaultCamelContext. In large systems with lots
> of routes and on multicore systems, dynamically created routes (and many
> routes) can cause long delays and hang for long times since route creation
> and the starting of the camel route can occur in unison with synchronization.
> In a blueprint container, such as Karaf, this can cause timeouts on the
> bundle and camel routes will appear to hang indefinately. Thread dumps show
> the hangs occur on the synchronized call in getEndpoint(s). The fix for this
> is to use concurrent apis as much as possible and remove the synchronized
> code. I refactored the LRUCache/LRUSoftCache to use Google's
> ConcurrentLinkedHashMap (ASL2 License
> http://code.google.com/p/concurrentlinkedhashmap) and removed the
> synchronized code that locks the endpoints object. This should remove the
> hangs since the locks are no longer required. Since COncurrentLinkedHashmap
> is not OSGi ready, I have shaded the classes in core. On my executions, all
> unit tests pass with this refactoring using the concurrent code. This should
> speed up Camel on multicore systems that have lots of routes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
