如何在另一个线程上运行阻塞代码并使http请求立即返回

Question

我们开始了一个新的项目与QUOKUS和穆特尼，并创建了一堆endpoint与QUOKUS@Funq，到目前为止一切都很好。现在我们想在其中一个endpoint中处理一些非常耗时的事情，我们期望的是，一旦用户单击一个按钮从前端发送超文本传输协议请求并点击这个特定的endpoint，我们将返回202接受立即从后端将耗时的操作处理留在另一个线程中，然后在完成后相应地向用户发送通知电子邮件。

我知道这可以用@Async或CompletableFuture来完成，但是现在我们想用Mutiny来完成。基于我如何阅读Mutiny留档https://smallrye.io/smallrye-mutiny/guides/imperative-to-reactive，runSubcriptionOn将通过在另一个线程上运行耗时的方法来避免阻塞调用者线程，我的测试显示耗时的代码确实在不同的线程。然而，超文本传输协议请求不会立即返回，它仍然挂起，直到耗时的方法完成执行（正如我在浏览器的开发工具中观察到的）。我是否误解了runSubcriptionOn的工作原理？我如何实现此功能与穆特尼？

我的@Funqendpoint如下所示

@Inject
MyService myService;

@Funq("api/report")
public Uni<String> sendReport(MyRequest request) {
    ExecutorService executor = Executors.newFixedThreadPool(10, r -> new Thread(r, "CUSTOM_THREAD"));

    return Uni.createFrom()
        .item(() -> myService.timeConsumingMethod(request))
        .runSubscriptionOn(executor);
} 

编辑：我根据@Ladicek的答案使用Uni找到了解决方案。在深入挖掘Quarkus和Uni之后，我有一个后续问题：

目前，我们的大多数阻塞方法都是而不是在服务级别上返回Uni，相反，我们从它们返回的内容（即对象或列表）创建Uni对象，并在它们的endpoint中返回控制器级别上的Uni，如下所示

返回Uni。createFrom（）。项目（）-

正如@Ladicek所解释的，我不必使用。显式运行subscriptionon，因为IO阻塞方法将自动在工作线程上运行（正如我在服务级别上的方法不返回Uni一样）。这有什么坏处吗？我的理解是，这将导致更长的响应时间，因为它必须在I/O线程和工作线程之间跳转，对吗？

对此的最佳实践是什么？我是否应该总是返回Uni用于服务级别上的阻塞方法，以便它们也可以在I/O线程上运行？如果是这样，我想我将总是需要调用. runSubcriptionOn来在不同的工作线程上运行它，以便I/O线程不被阻塞，对吗？




Answer 1

返回一个Uni，基本上就是说当Uni完成时，响应就完成了。您想要的是在线程池上运行操作并返回完整的响应（Uni与否，这无关紧要）。

顺便说一下，您正在为每个请求在方法中创建一个额外的线程池，而不是关闭它。那是错误的。您希望为所有请求创建一个线程池（例如，在@PostConstruct方法中），并在应用程序结束时（在@PreDestroy方法中）理想地将其关闭。