Panache @ReactiveTransactional在Kafka消息处理中超时无堆栈跟踪求助

核心问题 #

你遇到的超时问题，本质是事务上下文与消息确认机制的协同错误，加上手动获取会话导致的连接池耗尽。前4次正常是因为连接池初始连接被耗尽后，后续请求无法获取连接，最终触发超时。

具体修复步骤 #

1. 移除手动获取Panache会话的代码 #

@ReactiveTransactional注解已经会自动管理事务和会话，手动调用Panache.getSession()会额外创建会话实例，快速耗尽连接池。修改storeMetamodels方法：

private Uni<Void> storeMetamodels(Message<String> message) {
    List<EntityMetamodel> metamodels = Lists.newArrayList();
    for (String metamodelDsl : metamodelDsls.getMetamodelDsls()) {
        try {
            EntityMetamodel metamodel = new EntityMetamodel();
            metamodel.setJsonSchema("{}");
            metamodels.add(metamodel);
        } catch (IOException e) {
            Log.error(e, e);
        }
    }

    // 直接使用Panache的persistAll，事务上下文会自动提供会话
    return EntityMetamodel.persistAll(metamodels)
            .onItem().invoke(() -> Log.info("批量存储完成"));
}

2. 修正消息确认的时机 #

不要在onItemOrFailure().invoke()里同步调用ack()/nack()，因为invoke是在EventLoop线程执行，可能导致事务未完成就确认消息。应该用链式调用让Uni流控制确认逻辑：

@Incoming("words-in")
@ReactiveTransactional
public Uni<Void> storeToDB(Message<String> message) {
    return storeMetamodels(message)
            // 事务成功提交后再确认消息
            .onItem().invoke(message::ack)
            // 事务失败时拒绝消息
            .onFailure().invoke(throwable -> {
                Log.error(throwable, "存储失败");
                message.nack(throwable);
            });
}

3. 调整连接池与超时配置（可选） #

如果仍然出现超时，在application.properties中调整Hibernate Reactive连接池参数：

# 调整连接池大小，根据业务需求设置
quarkus.hibernate-reactive.pool.max-size=10
# 增加事务超时时间
quarkus.hibernate-reactive.transaction.timeout=30s
# Kafka消息处理超时
quarkus.smallrye-reactive-messaging.kafka.words-in.consumer.timeout=30s

为什么RestEasy Reactive下正常？ #

RestEasy Reactive的请求生命周期是单次请求绑定一个会话/事务，请求完成后会话会被及时回收。而消息消费是长生命周期的循环，手动获取会话如果没有正确释放，会快速耗尽连接池，导致后续请求超时。

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