我有一个不错的快速任务调度组件（Windows 服务，但这是无关紧要的），它订阅了一个内存队列中的待办事项。
队列的填充速度非常快......当我说快速时，我的意思是快速......如此之快，以至于我遇到了某些特定部分的问题。
队列中的每个项目都会附加一个“类别”，然后传递到 WCf 端点进行处理，然后保存在远程数据库中。
这提出了一个问题。
“队列”可以每分钟处理数百万个项目，而 WCF 端点实际上每秒只能处理大约 1000 到 1200 个项目，其中许多是“堆叠”的，以便等待插槽将它们转储到数据库.
我的 WCF 客户端配置为调用触发并忘记（故意）我的问题是，当调用偶尔会发生超时，那就是头痛开始的时候。
线程似乎在超时后停止，没有进入我的 catch 块……只是坐在那里，更令人困惑的是，这是一个间歇性的事情，这只发生在队列处理极端负载和 WCF 端点时被过度征税，即使在那种情况下，这种情况也只会每两周发生一次。
此代码24/7 全天候在服务器上不断运行。
所以......我的问题......我怎样才能确定导致我的问题的边缘情况，以便我可以解决它？
一些额外的信息：
调用 WCF 端点的客户端似乎自动“限制自己”，因为我限制了进行调用的线程数量，并且代码一直挂起，直到调用被认为完成（我认为这是一个 http 级别的事情因为我没有向服务询问我的方法调用的结果）。
与 EF 对话的 db 似乎永远不会打开超过固定数量的与 db 的连接（数量也很低，这很酷），并且来自呼叫接收的 WCF 端点似乎超级可靠。
问题似乎是从队列处理器到 WCf 端点。
队列处理器有我的 WCF 端点客户端的单个实例，它重用于所有调用......（每次调用重建此端点是一种好习惯吗？ - 请记住此处的调用次数）。
最后说明：
它是一个特殊的功能“模块”，在一次重载几个小时的情况下它是稳定的，但由于某种原因，这种奇怪的事情发生了，导致整个工作停止并且没有恢复。该调用包含在 try catch 中，但似乎即使 catch 被命中（不能保证），代码也不会按预期恢复/退出......它只是挂起。
有任何想法吗？
请让我知道我是否可以添加任何其他内容来帮助解决此问题。
编辑1：
绑定 - basicHttpBinding
错误处理 - 除了将 WCF 调用包装在 try catch 中之外，没有编写任何代码。