Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Fri, 19 Aug 2011 01:00:39 +0000 (UTC)
From: "Hadrian Zbarcea (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <910435870.51491.1313715639007.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1747510890.47955.1313644767356.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (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.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hadrian Zbarcea resolved CAMEL-4345.
------------------------------------

    Resolution: Fixed

Fixed checkstyle and also removed the OSGi export of the google stuff. The =
intent I believe was to make it accessible to components, but we can do tha=
t via a utility factory if/when needed.

Thanks Jeff!

> 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
>            Assignee: Hadrian Zbarcea
>         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