[
https://issues.apache.org/jira/browse/CAMEL-23239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated CAMEL-23239:
------------------------------------
Description:
h2. Motivation
Camel provides dedicated components for specific caching/store technologies
(Caffeine, Redis, Infinispan, etc.), each with its own API surface. This works
well when users need the full feature set of a specific technology, but it
creates friction when the actual need is simple: store and retrieve key-value
pairs.
The {{camel-state-store}} component follows the same "choose the problem, not
the technology" pattern that Camel already uses successfully in other areas:
* {{camel-sql}} / {{camel-jdbc}} — generic SQL over any JDBC database, without
locking into a vendor
* {{camel-jms}} — generic messaging over any JMS provider (with
{{camel-activemq}}, {{camel-amqp}} as pre-configured variants)
* {{camel-jcache}} — generic caching via JSR-107 over any compliant
implementation
Similarly, {{camel-state-store}} provides a unified key-value API where:
* Users choose the capability first ("I need a key-value store") rather than a
specific technology
* The backend is swappable without changing route logic — develop with
in-memory, deploy with Redis or Infinispan
* The API surface is intentionally minimal (put, get, delete, contains, keys,
clear) — unlike the full-featured technology-specific components
h2. Difference from existing cache components
|| || camel-state-store || camel-caffeine-cache / camel-infinispan / etc. ||
| *Focus* | Simple key-value store abstraction | Full feature set of a specific
technology |
| *Backend* | Pluggable via {{StateStoreBackend}} interface | Fixed to one
technology |
| *API* | Minimal: put, get, delete, contains, keys, clear | Rich: queries,
events, statistics, pub/sub, etc. |
| *Use case* | Portability, simplicity, migration from MuleSoft Object Store |
Deep integration with a specific product |
h2. Features
* New {{camel-state-store}} component providing a simple, unified key-value
store API with pluggable backends
* Supports operations: {{put}}, {{putIfAbsent}}, {{get}}, {{delete}},
{{contains}}, {{keys}}, {{size}}, {{clear}}
* Per-message TTL override via {{CamelStateStoreTtl}} header
* Multi-module structure with pluggable backends:
** {{camel-state-store}}: core + in-memory backend ({{ConcurrentHashMap}}, lazy
TTL)
** {{camel-state-store-caffeine}}: Caffeine cache with per-entry variable expiry
** {{camel-state-store-redis}}: Redisson {{RMapCache}} with native TTL
** {{camel-state-store-infinispan}}: Hot Rod client with lifespan TTL
* Custom backends via {{StateStoreBackend}} interface and bean references
h2. Design decision: StateStoreBackend interface location
We considered moving the {{StateStoreBackend}} interface to {{camel-api}}
alongside existing SPIs ({{IdempotentRepository}}, {{AggregationRepository}},
{{StateRepository}}). We decided against it because:
* The existing {{camel-api}} SPIs are there because core EIPs consume them
(idempotent consumer, aggregator). {{StateStoreBackend}} is only consumed by
the component itself.
* The existing SPIs have different semantics (two-phase confirm/rollback,
Exchange serialization) that don't map to a simple key-value store.
* Moving it would add API surface with stricter stability guarantees for no
practical benefit today.
If a future core EIP needs a generic key-value store, the interface can be
promoted then.
was:
Add a new camel-state-store component providing a simple, unified key-value
store API with pluggable backends.
Features:
- Supports operations: put, get, delete, contains, keys, clear
- Default in-memory backend using ConcurrentHashMap with optional TTL (lazy
expiry)
- Custom backends via StateStoreBackend interface and bean references
- Operations configurable via URI option or CamelStateStoreOperation header
- Fills a gap for users migrating from MuleSoft (which has Object Store
built-in)
> Add camel-state-store component with pluggable key-value store
> --------------------------------------------------------------
>
> Key: CAMEL-23239
> URL: https://issues.apache.org/jira/browse/CAMEL-23239
> Project: Camel
> Issue Type: New Feature
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 4.19.0
>
>
> h2. Motivation
> Camel provides dedicated components for specific caching/store technologies
> (Caffeine, Redis, Infinispan, etc.), each with its own API surface. This
> works well when users need the full feature set of a specific technology, but
> it creates friction when the actual need is simple: store and retrieve
> key-value pairs.
> The {{camel-state-store}} component follows the same "choose the problem, not
> the technology" pattern that Camel already uses successfully in other areas:
> * {{camel-sql}} / {{camel-jdbc}} — generic SQL over any JDBC database,
> without locking into a vendor
> * {{camel-jms}} — generic messaging over any JMS provider (with
> {{camel-activemq}}, {{camel-amqp}} as pre-configured variants)
> * {{camel-jcache}} — generic caching via JSR-107 over any compliant
> implementation
> Similarly, {{camel-state-store}} provides a unified key-value API where:
> * Users choose the capability first ("I need a key-value store") rather than
> a specific technology
> * The backend is swappable without changing route logic — develop with
> in-memory, deploy with Redis or Infinispan
> * The API surface is intentionally minimal (put, get, delete, contains, keys,
> clear) — unlike the full-featured technology-specific components
> h2. Difference from existing cache components
> || || camel-state-store || camel-caffeine-cache / camel-infinispan / etc. ||
> | *Focus* | Simple key-value store abstraction | Full feature set of a
> specific technology |
> | *Backend* | Pluggable via {{StateStoreBackend}} interface | Fixed to one
> technology |
> | *API* | Minimal: put, get, delete, contains, keys, clear | Rich: queries,
> events, statistics, pub/sub, etc. |
> | *Use case* | Portability, simplicity, migration from MuleSoft Object Store
> | Deep integration with a specific product |
> h2. Features
> * New {{camel-state-store}} component providing a simple, unified key-value
> store API with pluggable backends
> * Supports operations: {{put}}, {{putIfAbsent}}, {{get}}, {{delete}},
> {{contains}}, {{keys}}, {{size}}, {{clear}}
> * Per-message TTL override via {{CamelStateStoreTtl}} header
> * Multi-module structure with pluggable backends:
> ** {{camel-state-store}}: core + in-memory backend ({{ConcurrentHashMap}},
> lazy TTL)
> ** {{camel-state-store-caffeine}}: Caffeine cache with per-entry variable
> expiry
> ** {{camel-state-store-redis}}: Redisson {{RMapCache}} with native TTL
> ** {{camel-state-store-infinispan}}: Hot Rod client with lifespan TTL
> * Custom backends via {{StateStoreBackend}} interface and bean references
> h2. Design decision: StateStoreBackend interface location
> We considered moving the {{StateStoreBackend}} interface to {{camel-api}}
> alongside existing SPIs ({{IdempotentRepository}}, {{AggregationRepository}},
> {{StateRepository}}). We decided against it because:
> * The existing {{camel-api}} SPIs are there because core EIPs consume them
> (idempotent consumer, aggregator). {{StateStoreBackend}} is only consumed by
> the component itself.
> * The existing SPIs have different semantics (two-phase confirm/rollback,
> Exchange serialization) that don't map to a simple key-value store.
> * Moving it would add API surface with stricter stability guarantees for no
> practical benefit today.
> If a future core EIP needs a generic key-value store, the interface can be
> promoted then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
