This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 469c1d7e4f4c CAMEL-24622: docs - add the infinispan recovery note to
the 4.22 and 4.18 upgrade guides (#26159)
469c1d7e4f4c is described below
commit 469c1d7e4f4cf80456397eacff574860125d84f7
Author: Andrea Cosentino <[email protected]>
AuthorDate: Mon Sep 7 14:04:16 2026 +0200
CAMEL-24622: docs - add the infinispan recovery note to the 4.22 and 4.18
upgrade guides (#26159)
The aggregation repository fix shipped on camel-4.22.x (#26140) and
camel-4.18.x
(#26141), and each backport added the note to the guide on its own branch.
The
guides for every release line are also kept on main, where the note was
missing,
so main did not describe what 4.22.1 and 4.18.5 actually change.
Same text as the branches, placed under the patch section the change ships
in.
Claude-Session: https://claude.ai/code/session_012uKc65kdeJHCcG7bmeA7SQ
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
---
.../ROOT/pages/camel-4x-upgrade-guide-4_18.adoc | 18 ++++++++++++++++++
.../ROOT/pages/camel-4x-upgrade-guide-4_22.adoc | 18 ++++++++++++++++++
2 files changed, 36 insertions(+)
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
index 64ac783abd68..cc831ec08821 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_18.adoc
@@ -127,6 +127,24 @@ The option was declared and documented but never read, so
it had no effect. `jso
the response MIME type of the request to `application/json`, so the model is
asked to answer with
JSON. The default `false` leaves the request untouched.
+=== camel-infinispan - the aggregation repository keeps completed exchanges
for recovery
+
+`InfinispanAggregationRepository` implements
`RecoverableAggregationRepository`, but it had no recovery
+store: `remove` deleted the completed exchange outright, `confirm` removed the
exchange id from a cache
+keyed by correlation key, and `scan` returned the correlation keys of the
aggregations still in progress.
+The recovery task therefore re-delivered aggregations that were still
accumulating, marked them
+`CamelRedelivered`, and sent them to the dead letter channel once
`maximumRedeliveries` was reached, while
+exchanges that genuinely failed after completion could never be recovered.
+
+A completed exchange is now kept in the same cache under a
`camel-recovery:<exchange id>` key until it is
+confirmed, which is what `scan` reports and `recover` reads. `getKeys`
continues to report only the
+aggregations in progress.
+
+Routes that set `useRecovery=false` are unaffected. Routes that left recovery
enabled, which is the
+default, stop seeing in-progress aggregations re-delivered, and start seeing
genuine recovery. The cache
+now also holds one entry per completed and not yet confirmed exchange; those
entries are removed on
+confirmation.
+
== Upgrading from 4.18.3 to 4.18.4
=== camel-core - Multicast EIP honors UseOriginalAggregationStrategy
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
index 553d1b1fdafa..ffd0e77298ad 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_22.adoc
@@ -127,6 +127,24 @@
from("spring-redis://localhost:6379?command=SUBSCRIBE&channels=myChannel"
Setting the `serializer` option to a custom `RedisSerializer` bypasses the
filter entirely, since
Camel then no longer controls how the payload is read.
+=== camel-infinispan - the aggregation repository keeps completed exchanges
for recovery
+
+`InfinispanAggregationRepository` implements
`RecoverableAggregationRepository`, but it had no recovery
+store: `remove` deleted the completed exchange outright, `confirm` removed the
exchange id from a cache
+keyed by correlation key, and `scan` returned the correlation keys of the
aggregations still in progress.
+The recovery task therefore re-delivered aggregations that were still
accumulating, marked them
+`CamelRedelivered`, and sent them to the dead letter channel once
`maximumRedeliveries` was reached, while
+exchanges that genuinely failed after completion could never be recovered.
+
+A completed exchange is now kept in the same cache under a
`camel-recovery:<exchange id>` key until it is
+confirmed, which is what `scan` reports and `recover` reads. `getKeys`
continues to report only the
+aggregations in progress.
+
+Routes that set `useRecovery=false` are unaffected. Routes that left recovery
enabled, which is the
+default, stop seeing in-progress aggregations re-delivered, and start seeing
genuine recovery. The cache
+now also holds one entry per completed and not yet confirmed exchange; those
entries are removed on
+confirmation.
+
== Upgrading Camel 4.21 to 4.22
=== camel-tika
