[
https://issues.apache.org/jira/browse/CAMEL-24046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095839#comment-18095839
]
Federico Mariani commented on CAMEL-24046:
------------------------------------------
Pull request: https://github.com/apache/camel/pull/24657
_Claude Code on behalf of Federico Mariani_
> camel-sql - JdbcCachedMessageIdRepository: failed insert permanently poisons
> the cache; cache is not thread-safe
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24046
> URL: https://issues.apache.org/jira/browse/CAMEL-24046
> Project: Camel
> Issue Type: Bug
> Components: camel-sql
> Reporter: Federico Mariani
> Assignee: Federico Mariani
> Priority: Major
>
> Two related defects in JdbcCachedMessageIdRepository:
> 1. {{add(key)}} puts the key into the in-memory cache *before* calling
> {{super.add(key)}}. If the database insert fails (outage, PK race with
> another node) the exception propagates and the idempotent consumer never
> processes the message - but the key stays in the cache, so every redelivery
> is rejected as a duplicate. The message is never processed and never stored
> until the JVM restarts. Reproduced: after a failed insert, {{contains(key)}}
> returns true for a key that was never stored.
> 2. The cache is a plain {{HashMap}} mutated from concurrent consumer threads
> with no synchronization, and the {{cache}} field is non-volatile (a runtime
> {{reload()}} may never become visible to other threads). Concurrent puts
> during resize can lose entries (duplicate processing) or corrupt buckets. The
> hit/miss counters are unsynchronized ints.
> Fix: populate the cache only after the insert succeeds, use a
> ConcurrentHashMap with safe publication, and make the counters thread-safe.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
