java - 为什么我不应该将 PoolingHttpClientConnectionManager 与 FutureRequestExecutionService 一起使用？

Question

我正在编写一个需要运行许多并行 http 请求的服务。它也将部署在自动扩展环境中，但我希望从每个服务实例中获得尽可能多的性能。

我看到这篇文章How to determine the maximum number of simultaneous connections for a given `HttpClient` instance并注意到建议不要混合这两个类别。

我很好奇为什么。基本上，我想将 http 客户端作业提交到执行程序服务，并且我希望使用 http 连接池来重用 http 连接。也许，我想得太多了，但我不明白为什么将这两个类/概念组合在一个应用程序中是一个坏主意。

此外，我注意到该响应中给出的示例为每个 FutureRequestExecutionService 使用一个 http 客户端实例。 。 。这让我有点紧张，但 CloseableHttpClient 是线程安全的，所以也许我的担心是不必要的。

此外，对于我的代码提交的大多数客户端任务，我不关心响应是否为 200，如果不是，我只是计划增加错误跟踪指标并可能记录异常，所以我'我正在考虑走回调路线。在这一点上，我不清楚回调将在哪里运行。如果我的线程池线程运行并完成，即不会阻塞 http 请求 future。 。 。那么回调代码是哪个线程运行的呢？

Answer 1

该帖子建议不要“... PoolingHttpClientConnectionManager 和 FutureRequestExecutionService 连接代码的紧密耦合...”。没有理由不将 FutureRequestExecutionService 与 PoolingHttpClientConnectionManager 一起使用。