Wcf服务正在等待NServiceBus的回复，永远不会到来

Question

想象一下以下设置：Silverlight客户端通过网络使用WCF服务通过网络传输序列化命令，WCF服务反过来将命令反序列化并使用NServiceBus将其发送到通用主机负责处理该命令。 WCF服务在发送命令时注册了一个要调用的回调函数。通用主机验证命令并返回错误代码（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的一些可扩展性优势（在后期使用分发器）。
• 我不想承载一个gazillion WCF服务（每个命令一个），这就是为什么我制作了一个类似总线的WCF服务。
• 尽管这是一些请求/响应风格，但我最关心的是如何优雅地处理不经过的命令回复。

Answer 1

你可以开发任何你想要的消息类型，IMessage只是一个标记接口。如果您检查服务mex端点提供的WSDL文件，则不会提及IMessage，因此您可以在服务中定义您喜欢的任何命令。既然如此，你应该可以使用提供的WCF主机。

我能够重现您使用内置的WCF托管选项描述的问题。当引发异常时，整个事务将回滚并且包含Bus.Return，因此该服务从不会得到响应。

我发现了一个可以提供的解决方案，但我建议您重新考虑如何使用该服务。如果你真的想在一个单独的过程中做一些昂贵的操作，那么我建议你在你的WCF端点中完成一个Bus.Send到另一个过程。这将确保您的客户端已成功接收到该命令并正在进行工作。从那里它将由服务器来完成命令（一些前期验证将有助于确保其成功）。如果命令没有成功完成，应该在另一个通道上公布（客户端的一些背景轮询）。