camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-4345) Synchronized code causes long delays and hangs for big applications especially with Blueprint
Date Thu, 18 Aug 2011 13:29:27 GMT


Claus Ibsen commented on CAMEL-4345:

Nice patch.

By shading it into camel-core I like the fact that the camel-core dependency don't change.
However are there people who would not like shading this into camel-core?

And are there any Apache policy that would discourage this fact?
eg the JAR contains .class files which are not from Apache ?

If just the JDK had this class already. Even JDK7 dont have it, right?

> Synchronized code causes long delays and hangs for big applications especially with Blueprint
> ---------------------------------------------------------------------------------------------
>                 Key: CAMEL-4345
>                 URL:
>             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
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:


View raw message