gnodet opened a new pull request, #23796: URL: https://github.com/apache/camel/pull/23796
[CAMEL-23686](https://issues.apache.org/jira/browse/CAMEL-23686) ## Summary - Replace `ConcurrentHashMap` with `FlatMap` (flat `Object[]` array) for exchange properties - Make properties lazy in `DefaultPooledExchange` (was eagerly created in all constructors) ## Why ConcurrentHashMap is not needed The `ConcurrentHashMap` was introduced in [CAMEL-715](https://issues.apache.org/jira/browse/CAMEL-715) (2008) to fix a `ConcurrentModificationException` in the old `thread()` DSL where one thread modified properties while another iterated them. The test that reproduced the issue (`Camel715ThreadProcessorTest`) even says in its javadoc: > *"An old unit test from CAMEL-715 which reproduced a problem which we don't have anymore in Camel threads EIP and the routing engine."* The modern routing engine ensures single-threaded access per exchange. Message headers (`CaseInsensitiveMap`) are already explicitly documented as not thread-safe. Exchange properties don't need stronger guarantees. ## FlatMap design A `Map<String, Object>` backed by a flat `Object[]` with alternating `{key, value, key, value, ...}` pairs: - For ≤8 entries: faster than HashMap (linear scan beats hash + pointer chasing, single cache line) - Zero per-entry object overhead (no `Node` objects) - Default capacity: 4 entries (one `Object[8]` array = ~48 bytes vs ConcurrentHashMap's ~200+ bytes) - Grows the array on demand for rare cases with many properties ## Benchmark expectations - Typical exchange has 2-5 user properties (timer sets 4: COUNTER, NAME, PERIOD, FIRED_TIME) - 325K `ConcurrentHashMap` instances at 64 bytes each = 20 MB → replaced by `FlatMap` at ~48 bytes = ~15 MB - Pooled exchanges that never use properties: 0 bytes (was 200+ bytes from eager `ConcurrentHashMap`) ## Test plan - [x] 7,127 camel-core tests pass (0 failures) - [x] 370 exchange/property-related tests pass -- 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]
