WCF 客户端导致服务器挂起直到连接故障

Question

下面的文字是为这个问题扩展和添加颜色的努力:

如何防止行为不端的客户关闭整个服务？

我基本上有这样的场景:WCF 服务启动并运行，客户端回调具有直接、简单的单向通信，与此没有太大区别:

public interface IMyClientContract
{
  [OperationContract(IsOneWay = true)]
  void SomethingChanged(simpleObject myObj);
}

我正在从服务到最终将大约 50 个并发连接的客户端每秒调用此方法数千次，并且延迟尽可能低(<15 毫秒会很好)。这工作正常，直到我在连接到服务器的客户端应用程序之一上设置断点，然后一切都挂起，服务可能挂起 2-5 秒后，其他客户端都没有收到任何数据大约 30 秒左右，直到服务注册连接故障事件并断开有问题的客户端。在此之后，所有其他客户端继续以他们愉快的方式接收消息。

我已经研究了 serviceThrottling、并发调整、设置线程池最小线程、WCF 秘诀和整个 9 码，但归根结底这篇文章 MSDN - WCF essentials, One-Way Calls, Callbacks and Events准确地描述了我遇到的问题，而没有真正提出建议。

The third solution that allows the service to safely call back to the client is to have the callback contract operations configured as one-way operations. Doing so enables the service to call back even when concurrency is set to single-threaded, because there will not be any reply message to contend for the lock.

但在文章前面它描述了我看到的问题，仅从客户的角度来看

When one-way calls reach the service, they may not be dispatched all at once and may be queued up on the service side to be dispatched one at a time, all according to the service configured concurrency mode behavior and session mode. How many messages (whether one-way or request-reply) the service is willing to queue up is a product of the configured channel and the reliability mode. If the number of queued messages has exceeded the queue's capacity, then the client will block, even when issuing a one-way call

我只能假设相反的情况是正确的，发送到客户端的排队消息数量超过了队列容量，线程池现在充满了试图调用此客户端的线程，这些线程现在都被阻塞了。

处理这个问题的正确方法是什么？我是否应该研究一种方法来检查每个客户端在服务通信层排队的消息数量并在达到某个限制后中止它们的连接？

似乎如果 WCF 服务本身在队列填满时阻塞，那么每当一个客户端的队列已满时，我可以在服务内部实现的所有异步/单向/即发即弃策略仍然会被阻塞。

Answer 1

不太了解客户端回调，但听起来类似于通用 wcf 代码阻塞问题。我经常通过生成一个 BackgroundWorker 并在线程中执行客户端调用来解决这些问题。在此期间，主线程会计算子线程占用的时间。如果子线程在几毫秒内还没有完成，主线程就会继续前进并放弃该线程(它最终会自行死亡，因此不会出现内存泄漏)。这基本上就是 Mr.Graves 用短语“即发即忘”所建议的。