Very unscientifically testing this a 200 route count with 20 prepped exchanges went from 20 secs to 8 seconds, more interestingly though a 400 route count with 500 exchanges each that previously caused either a hang or a oome now takes around 40 seconds with the majority of time spent on route building.
This is definitely far more concurrent and much closer to very dynamic. /je On Aug 18, 2011, at 20:00, "Hadrian Zbarcea (JIRA)" <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/CAMEL-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Hadrian Zbarcea updated CAMEL-4345: > ----------------------------------- > > Fix Version/s: 2.9.0 > >> 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 >> Assignee: Hadrian Zbarcea >> Fix For: 2.9.0 >> >> 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 >> 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 > >
