ranchauh commented on PR #27524: URL: https://github.com/apache/camel/pull/27524#issuecomment-6055269655
Hi @allthingssecurity , Thanks for the fix — the ReentrantLock does address the ConcurrentModificationException, but I'm concerned it only trades one problem for another. The original requirement in [CAMEL-25093](https://issues.apache.org/jira/browse/CAMEL-25093) is about supporting concurrent updateRoutes() calls from multiple threads, which implies the expectation that these calls can make progress in parallel. Serializing them with a lock means that under load (e.g. hundreds of iFlows deploying simultaneously), all threads queue up and deploy sequentially — which is arguably the same throughput as calling updateRoutes() from a single thread to begin with. The root causes identified in the Jira point to specific unsynchronized data structures: the ArrayList in XmlRoutesBuilderLoader, the shared list in DefaultModel.addCustomBean, and the HashMap in SimpleRegistry.bind etc. A coarse lock around the whole operation prevents the ConcurrentModificationException, but it also prevents any concurrency benefit. Would it be worth targeting the actual shared state with finer-grained fixes (e.g. CopyOnWriteArrayList, ConcurrentHashMap) so that the parse/build phase can still run concurrently and only the registration writes are serialized? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
