[
https://issues.apache.org/jira/browse/CAMEL-26395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Gabriel updated CAMEL-26395:
-----------------------------------
Description:
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.
was:
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.
> 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
> Priority: Major
>
> 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)
