我正在使用 Weblogic 12.2.1 和内置的 Jersey 客户端 2.21.1 每隔几个小时向远程系统发出一批 https 请求。
为此，我有一个带有@Scheduled 方法的@Singleton bean，它在特定时间由Weblogic 执行。因此，在每次执行 @Scheduled 方法时，我都会一个接一个地进行多个 https 调用。
所有请求都是同步的。
问题是由于某种原因，下一个请求在前一个请求之后延迟一分钟发送（根据 Wireshark 输出）。 Jersey 的调用被阻塞。响应立即出现。远程系统没有问题。
在 JUnit 测试（纯 java）中执行发送请求的相同代码没有延迟。所有请求立即通过。所以也许是 Weblogic 容器的问题。
有人有类似问题吗？
【问题讨论】：
标签： java-8 jersey-2.0 weblogic12c jersey-client
实际上，当我将客户端中的默认HttpUrlConnectorProvider 更改为ApacheConnectorProvider 时，请求之间不再有延迟。事实上，泽西岛的文件对此的陈述是：
...在复杂的环境（例如应用程序服务器）中，一些可池连接可能在您的应用程序启动之前就已经存在，这种方法不是 100% 可靠的，我们建议使用不同的客户端传输连接器，例如 Apache 连接器。
但如果您想使用客户端的多部分功能，又会出现另一个问题。对此，文档说：
警告
注意使用非默认连接器实现。在 WriterInterceptor 或 MessageBodyWriter 中处理 HTTP 标头存在问题。如果您需要更改标头字段，请不要使用 ApacheConnectorProvider 和 GrizzlyConnectorProvider，也不要使用 JettyConnectorProvider。例如，该问题适用于 Jersey Multipart 功能，该功能也会修改 HTTP 标头。
最后我发现自己不得不选择没有多部分的 ApacheConnector（快速请求）或多部分的慢速请求。是不是很有趣？
我想我应该花更多时间研究其他实际在 Java EE 环境中工作的 RESTful 客户端。
【讨论】：