Kratika Agrawal created IGNITE-28701:
----------------------------------------
Summary: CacheEntryListener / IgniteEvents: no per-cache event
listeners in Ignite 3.x
Key: IGNITE-28701
URL: https://issues.apache.org/jira/browse/IGNITE-28701
Project: Ignite
Issue Type: Bug
Environment: Apache Ignite:3.1.0 (migrated from 2.17.0)
JDK:Java 21 (LTS)
- Topology: Multi-node clusters; production target is 2–3 node SharedNothing
with both
in-memory (`aimem`) and persistent (`aipersist`) storage profiles. We also
run a single
embedded-node mode for inference workloads.
- Control plane: Notifications must propagate **across all nodes** of the
cluster on every
mutation — agent registry changes, master election, hot deployment events,
etc. The 2.x
`CacheEntryListener` fired on every node that hosted a partition; the 3.x
compute-broadcast
workaround has at-most-once semantics and is augmented with a safety-net poll
(`be.ignite.controldao.safety.poll.interval.ms`, default 30 s) to recover
dropped broadcasts.
- Latency SLA: CEP rules require sub-second reaction to control-plane changes.
Polling at
1 s is a regression from 2.x event-driven (≈0 latency) behavior.
Reporter: Kratika Agrawal
I think this is a major road block in migration this is affecting continuous
query ,eviction ,control table poll etc.
Ignite 2.x had two well-defined listening surfaces:
- `CacheEntryListener<K,V>` — JCache-compliant per-cache `onCreated` /
`onUpdated` / `onRemoved`
callbacks registered via
`CacheConfiguration.addCacheEntryListenerConfiguration(...)`.
- `Ignite.events().localListen(...)` — node-local distributed event listener
with `EventFilter`
for fine-grained filtering.
Both are removed in 3.1.0. The Ignite 3 docs suggest "use compute jobs or
partition-based
streaming" but neither replaces the synchronous, per-key callback semantics of
`CacheEntryListener`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
