Croway opened a new pull request, #24657: URL: https://github.com/apache/camel/pull/24657
JIRA: https://issues.apache.org/jira/browse/CAMEL-24046 Two related defects in `JdbcCachedMessageIdRepository`: 1. `add(key)` put the key into the in-memory cache *before* calling `super.add(key)`. If the database insert failed (outage, PK race with another node), the exception propagated and the idempotent consumer never processed the message — but the key stayed cached, so every redelivery was rejected as a duplicate. The message was never processed and never stored until JVM restart. 2. The cache was a plain `HashMap` mutated from concurrent consumer threads with no synchronization and a non-volatile field (a runtime `reload()` might never become visible to other threads); concurrent puts during resize can lose entries, causing duplicate processing. The hit/miss counters were unsynchronized ints. Changes: - Populate the cache only after the database insert succeeded - Use `ConcurrentHashMap` with a volatile field for safe publication on `reload()`, and `AtomicInteger` hit/miss counters (public getters unchanged) - New test simulating a DB failure during `add()`: `contains()` must return false and a redelivered `add()` must succeed once the DB is back (fails on current `main`, passes with the fix); existing cache hit/miss-count test passes unchanged, confirming counting semantics are preserved _Claude Code on behalf of Croway_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
