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