Apache Ignite本地监听器的回调函数是阻塞还是非阻塞的？

问题结论 #

首先明确：Apache Ignite的连续查询ContinuousQuery本地监听器的回调函数默认是阻塞执行的，不会自动开启独立线程异步处理。

详细说明 #

1. 回调的线程模型 #

监听器回调默认是在Ignite内部的ignite.continuous-query.pool线程池中的线程上同步执行的，同一个分区的事件默认会派发给同一个线程处理，保证事件顺序性。你的回调逻辑执行完之前，该线程不会被释放回线程池，也不会处理后续分配给它的其他事件。

2. 阻塞场景下process执行时间过长的风险 #

如果this.process(taskIds)执行时间过长，会引发以下问题：

• 事件积压：连续查询线程池的默认线程数和CPU核心数挂钩，线程被占满后，新产生的缓存事件会积压在内部队列中，队列满后新事件会被直接丢弃，导致你的业务逻辑漏处理数据。
• 影响其他监听器：该线程池是所有连续查询监听器共享的，你的慢回调会拖累节点上所有其他连续查询的事件处理速度。
• 死锁风险：如果process方法中存在对同缓存的写入操作，会触发新的缓存事件，而新事件又在等待空闲的连续查询线程，极端情况下会产生死锁。
• 严重时可能触发Ignite的系统线程阻塞检测，被判定为节点异常，被集群踢出。

3. 非阻塞实现方式与线程管理 #

Ignite本身没有提供内置的监听器异步执行配置，你需要自己将耗时的业务逻辑提交到自行管理的独立线程池来实现非阻塞，线程管理规则完全由你自己定义：

• 建议根据业务吞吐量配置独立的ThreadPoolExecutor，设置合理的核心线程数、最大线程数、队列容量和拒绝策略，避免内存溢出。
• 如果你的业务依赖事件处理的顺序，可以给每个缓存键哈希分配固定的线程，保证同一个键的事件按顺序处理。
• 注意要避免在自定义线程中使用Ignite的事务上下文传递，避免上下文丢失的问题。

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