使用Quarkus和hibernate-reactive的SQL连接耗尽

Question

我有一个Quarkus应用程序，它使用hibernate-reactive运行一些查询，而不是处理结果，然后通过Rest调用返回JSON。对于每个Rest调用5DB查询，最后一个查询将加载大约20k行：

    public Uni<GraphProcessor> loadData(GraphProcessor graphProcessor){
    return myEntityRepository.findByDateLeaving(graphProcessor.getSearchDate())
            .select().where(graphProcessor::filter)
            .onItem().invoke(graphProcessor::onNextRow).collect().asList()
            .onItem().invoke(g -> log.info("loadData - end"))
            .replaceWith(graphProcessor);
}

//In myEntityRepository
public Multi<MyEntity> findByDateLeaving(LocalDate searchDate){
    LocalDateTime startDate = searchDate.atStartOfDay();
    return MyEntity.find("#MyEntity.findByDate",
            Parameters.with("startDate", startDate)
                    .map()).stream();

}

这一切在前4次都很好，但在第5次我得到

 11:12:48:070 ERROR [org.hibernate.reactive.util.impl.CompletionStages:121] (147) HR000057: Failed to execute statement [$1select <ONE OF THE QUERIES HERE>]: $2could not load an entity: [com.mycode.SomeEntity#1]: java.util.concurrent.CompletionException: io.vertx.core.impl.NoStackTraceThrowable: Timeout
    at <16 internal lines>
io.vertx.sqlclient.impl.pool.SqlConnectionPool$1PoolRequest.lambda$null$0(SqlConnectionPool.java:202) <4 internal lines>
    at io.vertx.sqlclient.impl.pool.SqlConnectionPool$1PoolRequest.lambda$onEnqueue$1(SqlConnectionPool.java:199) <15 internal lines>
Caused by: io.vertx.core.impl.NoStackTraceThrowable: Timeout

我检查了https://quarkus.io/guides/reactive-sql-clients#pooled-connection-idle-timeout并配置了qukus.datource.reactive.id-timeout=1000

这本身并没有什么不同。我加了夸克.数据源.reactive.max-size=10

在再次超时之前，我能够运行10个Rest电话。在最大大小= 20的泳池设置中，我可以运行20次。因此，看起来每个Rest调用都会耗尽一个SQL连接，而不会再次释放它。

手动释放连接需要做些什么吗?还是这仅仅是一个错误？

Answer 1

问题是在反应性Rest方法上使用@阻塞。有关更多信息，请参见https://github.com/quarkusio/quarkus/issues/25138和https://quarkus.io/blog/resteasy-reactive-smart-dispatch/。

因此，如果您有一个rest方法返回例如Uni或Multi，就不要在调用中使用@阻塞。一开始我不得不添加它，因为我收到了一个异常，告诉我线程不能阻塞。这是由于一些CPU密集的计算。添加@阻塞使异常消失(在开发模式下，但在本机模式中出现了另一个问题)，但导致了这个SQL池问题。

真正的解决方案是使用emitOn来更改cpu密集型方法的线程：

 .emitOn(Infrastructure.getDefaultWorkerPool())
 .onItem().transform(processor::cpuIntensiveMethod)