[
https://issues.apache.org/jira/browse/CAMEL-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087605#comment-13087605
]
Claus Ibsen commented on CAMEL-4345:
------------------------------------
The osgi manifest contains import of the google code
{code}
Import-Package: com.googlecode.concurrentlinkedhashmap,javax.activatio
n;resolution:=optional,javax.management,javax.management.modelmbean,j
avax.management.remote,javax.naming,javax.naming.spi,javax.net.ssl,ja
vax.xml.bind;resolution:=optional,javax.xml.bind.annotation;resolutio
n:=optional,javax.xml.bind.annotation.adapters;resolution:=optional,j
avax.xml.namespace,javax.xml.parsers,javax.xml.stream;resolution:=opt
ional,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform
.sax,javax.xml.transform.stream,javax.xml.validation,javax.xml.xpath,
org.apache.xalan.xsltc.trax;resolution:=optional,org.osgi.framework;v
ersion="[1.4,2)",org.slf4j;version="[1.6,2)",org.w3c.dom,org.xml.sax
{code}
I cannot see that its being exported, so I would assume we are almost okay.
What if another bundle exports com.googlecode.concurrentlinkedhashmap,
then camel-core could potential pickup that instead from itself, or am I
mistaking?
> 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
> Assignee: Hadrian Zbarcea
> Fix For: 2.9.0
>
> 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
