Ignite Thin Client连续查询监听器丢事件问题求助

问题结论 #

该事件丢失问题确实仅在单节点Ignite场景下出现，核心原因是单节点与集群的事件投递机制差异：

• 集群模式下，缓存操作事件通过分布式事件总线在节点间广播，Thin Client监听器能稳定接收所有事件；
• 单节点模式下，本地缓存事件仅在本地处理，当监听与数据插入使用不同的Thin Client连接实例时，会触发本地事件总线的转发竞态，导致部分事件遗漏。而单线程插入时操作顺序可控，不会触发这类竞态，因此无丢失。

可行解决方案 #

1. 复用同一Thin Client实例 #

测试代码中使用了两个独立的IgniteClient实例（client1监听、client2插入），跨连接的事件投递在单节点下存在缺陷。改为复用同一个客户端实例完成监听和插入操作：

// 移除client2的创建逻辑，直接使用client1的缓存
ClientCache<Object, Object> cache2 = client1.cache("test");

2. 调整连续查询的投递参数 #

通过配置事件缓冲区大小和投递间隔，优化事件的批量投递可靠性：

ContinuousQuery<Object, Object> query = new ContinuousQuery<>();
// 添加远程过滤器（允许所有事件通过）
query.setRemoteFilterFactory(() -> new CacheEntryEventSerializableFilter<Object, Object>() {
    @Override
    public boolean evaluate(CacheEntryEvent<Object, Object> e) {
        return true;
    }
});
// 设置事件投递间隔（单位：毫秒），确保事件能及时批量推送
query.setTimeInterval(50);
// 增大事件缓冲区，避免因缓冲区溢出丢事件
query.setBufferSize(2000);

3. 升级Ignite版本 #

Ignite 2.15.0存在单节点Thin Client连续查询的事件投递bug，2.16.0及后续版本已修复该问题，升级到最新稳定版本可彻底解决此问题。

验证优化建议 #

将控制台打印改为计数统计，避免因输出延迟导致的“假丢失”判断：

private int eventCount = 0;

@Override
public void onUpdated(Iterable<CacheEntryEvent<?, ?>> cacheEntryEvents) throws CacheEntryListenerException {
    for (CacheEntryEvent<?, ?> event : cacheEntryEvents) {
        eventCount++;
    }
    System.out.println("累计接收事件数：" + eventCount);
}

内容的提问来源于stack exchange，提问作者lonesomerain