Markus Gabriel created CAMEL-26395:
--------------------------------------
Summary: camel-redis - Potential exchange loss in
RedisAggregationRepository optimistic removal
Key: CAMEL-26395
URL: https://issues.apache.org/jira/browse/CAMEL-26395
Project: Camel
Issue Type: Bug
Reporter: Markus Gabriel
In {{{}RedisAggregationRepository.remove(){}}}, the optimistic branch executes
the delete and recovery staging as two separate, non-atomic operations:
{code:java}
if (!cache.remove(key, holder)) {
throw new OptimisticLockingException();
}
if (useRecovery) {
persistedCache.put(exchange.getExchangeId(), holder);
}{code}
{{}}
If the JVM crashes or gets killed right between {{cache.remove(...)}} and
{{persistedCache.put(...)}} (or if the {{put}} throws an exception), the
exchange is permanently removed from the active cache without ever making it
into the recovery store.
The non-optimistic branch right below it already wraps this handoff in an
{{RTransaction}} to keep it atomic. It seems like the optimistic branch should
do the same to prevent dropping exchanges.
I'm happy to open a PR for this if the approach makes sense.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
