.Net SMTPClient 在 WAIT_CLOSE 后离开连接

Question

我有一个问题困扰着我。每隔 2 到 3 天，我就会收到与我们的 SMTP 提供商的连接，但这些连接并未完成关闭。运行服务器上的 netstat 显示状态为 CLOSE_WAIT 的连接。经过研究，我认为我已经将范围缩小到一个没有被妥善处理的物体。

特别是 .Net SMTPClient class 在以前版本的框架中没有实现 IDisposable。当我们迁移到 4.0 框架时，我们再也不需要返回并更新它，这意味着我们一直没有出现这些错误。然后几周前我们开始遇到这个问题。它是在我们的提供商的服务器出现故障时开始的。从理论上讲，他们可能仍然会遇到他们没有广播的间歇性问题。但无论哪种情况，我的代码都需要能够恢复并继续运行。

我检查了发送电子邮件的每一段代码，它们都已修复。每个 MailMessage 对象和每个 SMTPClient 对象都在一个 using 语句中。但是我仍然随机得到这个问题。当它确实发生时，似乎会非常接近地发生多次，然后几天都不会发生。

最糟糕的问题是，一旦我以这种状态结束与同一个服务器的两个连接，后续消息池等待额外的资源，但最终只是超时。重置服务可立即解决问题。

我知道有帖子说可以调整配置以允许更多同时连接。但这并不能解决问题，只是掩盖了一点。

Answer 1

我上面的说法是错误的。

"I know there are posts out there stating that the configuration can be adjusted to allow more simultaneous connections. But that doesn't fix the problem, just masks it a bit."

我调整了配置文件中允许的连接，希望它能给我更多时间来主动监控问题并主动解决问题，同时继续寻找解决方案。

一旦我添加了配置值，问题就完全停止了。

<system.net>
  <connectionManagement>
    <add address="{AddressGoesHere}" maxconnection="10" />
  </connectionManagement>
</system.net>

事实上，我没有立即应用我们较少使用的一项服务的配置更新，因为它处理的电子邮件较少并且不那么容易受到影响。最终那个坏了，而使用频率更高的那些仍然像魅力一样工作。

我很想知道更多原因。我最好的理解是我们正在尝试打开比允许的更多的服务器连接，这导致一些连接被挂断。默认的 2 个连接将它们堆积起来，在某些情况下，.NET 似乎在连接打开时超时，但在 OS 级别没有断开连接。（例如 28 秒等待连接，然后需要 3 秒处理但在 30 秒时被杀死。）

现在我已经允许 10 个连接，它们正在同时处理更多线程，而不是等待插槽打开。在过去的一周里，我对新配置没有任何问题。

我希望这可以帮助其他人睡得比我好几个晚上 :)

.Net SMTPClient 在 WAIT_CLOSE 后离开连接

.Net SMTPClient leaves connection in WAIT_CLOSE

c#

idisposable

smtpclient