Quarkus的SQL连接耗尽，Hibernate反应式花招

Question

我有一个Quarkus应用程序，它使用hibernate-reactive-panache运行一些查询，然后处理结果并通过Rest调用返回JSON。对于每个Rest调用，执行5 DB查询，最后一个查询将加载大约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://quar kus . io/guides/reactive-SQL-clients # pooled-connection-idle-time out并配置了quar kus . data source . reactive . idle-time out = 1000

这本身并没有什么不同。我增加了quarkus.datasource.reactive.max-大小=10

在再次超时之前，我能够运行10个Rest调用。在max-size=20的池设置下，我能够运行它20次。所以看起来每个Rest调用都会用完一个SQL连接，并且不会再次释放它。

是否需要执行某些操作才能手动释放连接，或者这仅仅是一个错误？

Answer 1

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

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

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

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