Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Thu, 18 Aug 2011 13:29:27 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <1023060982.49107.1313674167238.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1747510890.47955.1313644767356.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CAMEL-4345) Synchronized code causes long
 delays and hangs for big applications especially with Blueprint
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CAMEL-4345?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1308=
7005#comment-13087005 ]=20

Claus Ibsen commented on CAMEL-4345:
------------------------------------

Nice patch.

By shading it into camel-core I like the fact that the camel-core dependenc=
y 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 espec=
ially 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 ultim=
ately extending a LinkedHashMap through the LRUCache.  The LinkedHashMap is=
 obviously not thread safe, so it requires synchronized guards when accessi=
ng the endpoints object.  This especially happens in the getEndpoint(s) cal=
ls 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 o=
f 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 co=
ncurrent apis as much as possible and remove the synchronized code.  I refa=
ctored the LRUCache/LRUSoftCache to use Google's ConcurrentLinkedHashMap (A=
SL2 License http://code.google.com/p/concurrentlinkedhashmap) and removed t=
he synchronized code that locks the endpoints object.  This should remove t=
he hangs since the locks are no longer required.  Since COncurrentLinkedHas=
hmap is not OSGi ready, I have shaded the classes in core.  On my execution=
s, all unit tests pass with this refactoring using the concurrent code.  Th=
is 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