主机实例重新启动之前的 SMTP 发送适配器、错误和挂起消息
我有一个 BizTalk 应用程序，必须在早上 3 或 4 小时内发送数百封、近千封电子邮件。该应用程序将正常运行几天，然后似乎该应用程序会减慢速度，最终我会看到所有发出的消息都处于“活动”状态，但不执行任何操作，只是坐在那里，并发出此警告。 ..
适配器无法传输要发送到 URL“”的端口“”的消息。它将在为此发送端口指定的重试间隔后重新传输。详细信息：“传输无法连接到服务器。
我没有看到盒子上有任何异常负载，没有高 CPU、磁盘或网络利用率。
在我重新启动托管此 SMTP 发送端口的主机实例后，它们全部继续并运行良好，一两天，直到我再次遇到这个问题，
我一直在摸索可能导致此问题的原因......有什么想法吗？
I've got a BizTalk application that has to send out several hundred, close to a thousand emails over the course of 3 or 4 hours in the morning. The app will run fine for several days, then it seems that the app will slow way down, eventually I will see all of the out going messages in the 'active' state, but not doing anything, just sitting there, with this warning...
The adapter failed to transmit message going to send port "" with URL "". It will be retransmitted after the retry interval specified for this Send Port. Details:"The transport failed to connect to the server.
I don't see any unusual load on the box, no high CPU, disk, or Network utilization.
After I restart the host instance that is hosting this SMTP send port, they all continue and run fine, for a day or two until I have this issue again.
I've been scratching my head on what may be causing this issue... any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可能会查找限制条件，特别是内存限制 - （限制状态 4） - 对此使用 Perfmon 或 SCOM 计数器。
另外，在任务管理器中查看 BizTalk 服务主机的内存 - 并添加提交大小（即包括虚拟）。您的 Orch 可能没有释放内存或者内存消耗太大（例如，请记住在自定义程序集中使用 Dispose() XLangMessages）。
如果您确实发现限制状态 4，并且确定没有泄漏，您可能需要将限制阈值从 25 提高到 50 - 请参阅 此处。但恕我直言，文章中建议的 100% 听起来很危险。
Possibly look for throttling conditions, especially for Memory throttling - (Throttling State 4) - use Perfmon or SCOM on this counter.
Also, in task manager look at the Memory of your BizTalk service hosts - and add Commit Size (i.e. including virtual). It is possible that your Orchs aren't releasing memory or are too memory intensive (e.g. remember to Dispose() XLangMessages in custom assemblies).
If you do find Throttling state 4, and are sure that you aren't leaking, you might want to bump the throttling threshold up from 25 to say 50 - see here. But IMHO 100% as suggested in the article sounds dangerous.