Question

我有一个问题困扰着我。每隔2到3天，我最终会与我们的SMTP提供商建立联系，而这些提供商并未完成关闭。在服务器上运行netstat会显示状态为CLOSE_WAIT的连接。研究我以为我把它缩小到一个没有被妥善处理的物体。

特别是.Net SMTPClient类，在以前版本的框架中没有实现IDisposable。当我们迁移到4.0框架时，我们永远不需要返回并更新它，这意味着我们已经没有这些错误。几个星期前，我们开始遇到这个问题。当我们的提供商在他们的服务器上中断时，它就开始了。从理论上讲，他们可能仍然存在他们没有广播的间歇性问题。但在任何一种情况下，我的代码都需要能够恢复并继续前进。

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

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

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

Answer 1

我上面的陈述不正确。

＆＃34;我知道那里有帖子说明配置可以调整以允许更多同时连接。但那不是解决问题，只是掩盖它。＆＃34;

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

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

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

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

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

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

我希望这可以帮助别人睡几个晚上好好睡觉：）

.Net SMTPClient在WAIT_CLOSE中保留连接

1 个答案: