多个HttpClientHandler实例出现超时错误



我们编写了一个与外部API连接的应用程序。您需要有一个令牌才能与此api通信。令牌对于每个用户都必须是唯一的。为了获得令牌,我们需要使用属于该用户的客户端证书来调用端点。

我们通过对所有API请求使用1个静态HttpClientHandler实例来实现这一点。每个请求都设置了一个HttpClient,并给出了这个静态处理程序;并且只有客户端将被处置,则处理程序将保持活动。然而,为了获得代币;我们需要将证书添加到处理程序中。因此,在获取令牌时;我们使用一个新的HttpClientHandler实例来获取令牌。一旦获得令牌,我们就处理客户端和处理程序实例。

现在很多呼叫都失败了,并出现以下错误:

连接尝试失败是因为连接方在一段时间后没有正确响应,或者建立的连接失败是因为所连接的主机没有响应[ip]:443

大多数错误都发生在我们获得代币时。但有时一个普通的API调用会因为同样的错误而失败。

对方也对此问题进行了研究;他们给我们的最新结论是:在请求结束时,我们保持连接;因此该端口是为该连接保留的。然而,有时一个新的请求(我想是新的连接(试图从我们这边用同一个端口设置。防火墙正在阻止/删除这个新请求;因为此端口已在使用中。这就是为什么我们以这个超时错误结束。

这是有道理的;我们无法控制连接使用的端口。但为什么会发生这种情况呢?我有这样的理论,问题在于静态处理程序(支持10个并行连接,并保持这些连接处于非活动状态,但处于活动状态(和第二个(或更多个(其他处理程序的组合,这些处理程序可能认为一个端口是空的(因为这个端口上没有活动(,可能会尝试与该端口建立连接。但这只是一个理论;我找不到这方面的证据。

有人能证实这个理论吗;或者可能给出另一个解释为什么会出现这个问题?和/或是否有解决此问题的解决方案/解决方法?

Ho,我认为您正面临一个名为套接字耗尽的问题。尽管您对HTTP客户端执行dispose(),但它使用的套接字仍将保留一定的时间。为了防止这种情况,您需要一种机制,允许您重用HttpClients,从而重用它们使用的底层套接字。

推荐的方法是使用HttpClientFactory。该工厂将使用HttpClients构建一个池,并为您提供一个按需池,同时为您维护客户端池。

有关详细信息,请访问Microsoft Docs网站:https://learn.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests

相关内容

  • 没有找到相关文章

最新更新