Wcf服务等待来自NServiceBus的回复永远不会到来

Question

想象一下以下设置：Silverlight客户端使用WCF服务在网络上隧道传输序列化命令，该服务反过来反序列化命令并使用NServiceBus将其发送到负责处理命令的通用主机。 WCF服务在发送命令时注册了要调用的回调。通用主机验证命令并“返回”错误代码（0 ==成功或＆gt; 0 ==失败）。

注意：WCF服务是在内置WCF服务之后建模的。不同之处在于此WCF服务接收“通用命令”（不是IMessage），将其反序列化为实际命令（实现IMessage），然后将反序列化命令发送到总线。

当发生意外异常时，该命令会在错误队列中排队（在一定次数的重试之后）。此时，启动WCF服务处于空闲状态，不知道刚刚发生了什么。稍后，Silverlight客户端将根据WCF客户端代理配置超时。

我头脑中模糊的东西：

1. NServiceBus是否以任何方式处理此场景？何时抛出超时异常（如果有的话）？或者这是传奇专属的东西吗？
2. 假设我使用[OperationContract（AsyncPattern = true）]，是否有任何与WCF相关的超时设置会终止服务操作？或者以某种方式调用EndXXX方法？或者它会永远坐在那里，泄漏，等待永远不会来的东西？

继续进行的方式：

1. 重用现有的超时机制，只要事情不泄漏。
2. 在wcf服务和nservicebus之间建立我自己的超时机制。
3. 当命令进入错误队列时以某种方式通知wcf服务。
4. 使用WCF服务层中的完整回调消息处理程序构建我自己的异步通知机制。

我做过的事情：

1. 运行NServiceBus提供的示例。
2. 匆匆忙忙地说道。

欢迎任何关于如何继续的指导，无论是博客文章，邮件列表条目，......

选择当前方法的一些动机

• 我正在尝试利用NServiceBus的一些可扩展性优势（在后期使用分销商）。
• 我不想托管大量的WCF服务（每个命令一个），这就是我为什么要编写类似总线的WCF服务的原因。
• 尽管这有点请求/响应风格，但我最关心的是优雅地处理未通过的命令回复。

Answer 1

您可以开发任何类型的消息类型，IMessage只是一个标记界面。如果检查服务mex端点提供的WSDL文件，则不会引用IMessage，因此您可以在服务中定义任何您喜欢的命令。在这种情况下，您应该能够使用提供的WCF主机。

我能够使用内置的WCF托管选项重现您描述的问题。抛出异常时，将回滚整个事务，这包括Bus.Return，因此服务永远不会得到响应。

我发现了我可以提供的黑客攻击，但我建议您重新考虑如何使用该服务。如果您真的希望在单独的进程中执行一些昂贵的操作，那么我建议您在WCF端点中执行Bus.Send到另一个进程。这将确保您的客户端成功接收命令并且该工作正在进行中。从那里开始由服务器来完成命令（一些预先验证将有助于确保其成功）。如果命令未成功完成，则应在另一个通道上知道（从客户端进行一些背景轮询）。