Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 84482976F for ; Mon, 19 Sep 2011 17:45:32 +0000 (UTC) Received: (qmail 79441 invoked by uid 500); 19 Sep 2011 17:45:32 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 79368 invoked by uid 500); 19 Sep 2011 17:45:32 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 79358 invoked by uid 99); 19 Sep 2011 17:45:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2011 17:45:32 +0000 X-ASF-Spam-Status: No, hits=-2000.5 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Sep 2011 17:45:31 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id CBDD4A26B7 for ; Mon, 19 Sep 2011 17:45:09 +0000 (UTC) Date: Mon, 19 Sep 2011 17:45:09 +0000 (UTC) From: "Daniel Kulp (JIRA)" To: dev@camel.apache.org Message-ID: <1961233973.43065.1316454309831.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1747510890.47955.1313644767356.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CAMEL-4345?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CAMEL-4345: ------------------------------- Fix Version/s: 2.8.2 > 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 > Fix For: 2.8.2, 2.9.0 > > 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