处理双工绑定 WCF 应用程序中丢弃的客户端
我们在 WCF 应用程序中使用发布-订阅模型，该模型几乎遵循 Microsoft 示例：设计模式：基于列表的发布-订阅。
虽然该服务提供了 subscribe() 和 unsubscribe() 的概念，但在客户端终止或通道故障时处理清理的最佳实践是什么？目前，当客户端订阅时，我将处理程序附加到当前 InstanceContext 的 Closed 和 Faulted 事件（该服务使用 PerSession 实例上下文模式和 netTcpBinding）：
_communicationObject = OperationContext.Current.InstanceContext;
_communicationObject.Closed += OnClientLost;
_communicationObject.Faulted += OnClientLost;
OnClientLost 处理程序只是取消订阅客户端，但是：
- 上面的方法是否是一个好的实践，并且足够强大以捕获客户端断开双工通信时的所有情况？或者服务应该只处理在尝试与客户端通信时遇到的异常并处理清理吗？
- 除了取消订阅客户端回调处理程序之外，是否还应该执行任何进一步的清理，特别是在出现故障的情况下？
这个问题提出了类似的问题，但最终没有提供以下问题的答案：客户外部调用订阅和/或取消订阅的情况
谢谢
We are using a pub-sub model in our WCF application that pretty much follows the Microsoft sample: Design Patterns: List-Based Publish-Subscribe.
Whilst the service provides a notion of subscribe() and unsubscribe(), what is the best practice to handle the cleanup in the situation when a client dies or the channel faults? Currently, when a client subscribes I attach to handlers to the current InstanceContext's Closed and Faulted events (the service users an PerSession instance context mode and netTcpBinding):
_communicationObject = OperationContext.Current.InstanceContext;
_communicationObject.Closed += OnClientLost;
_communicationObject.Faulted += OnClientLost;
The OnClientLost handler simply unsubscribes the client, however:
- Is the above a good practice and alone robust enough to catch all situations when a client drops off the duplex communication? Or should the service just handle exceptions encountered at the point it attempts to communicate with the client and handle cleanup then?
- Aside from just unsubscribing the client call back handler, should any further cleanup be performed especially in the case of a fault?
This question poses a similar question but ultimately does not provide answers to the cases outside of the client calling subscribe and/or unsubscribe
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我做了一些测试，将处理程序附加到回调通道的 Closed 和 Faulted 事件，然后在服务器调用回调之前杀死客户端。在每次试验中，在服务器尝试调用回调之前，都会立即触发 Closed/Faulted 事件。尽管如此，我仍然将回调调用包装在 try-catch 块中，因为客户端通道的破坏可能会在另一个线程进入回调时发生。
唯一需要的清理工作是删除对回调通道的引用。 WCF 和垃圾收集器会完成剩下的工作。
I did some testing where I attached handlers to the Closed and Faulted events of the callback channel, then killed the client at the point just before the callback would be invoked by the server. On each trial, the Closed/Faulted event was fired instantaneously and before the server attempted to invoke the callback. All the same, I still have the callback invocation wrapped in a try-catch block because the destruction of the client channel could occur just as another thread was entering the callback.
The only clean-up necessary was to remove the reference to the callback channel. WCF and the garbage-collector do the rest.
处理这些事件将使您的订阅者列表保持同步。它确实足够坚固。请记住，如果客户端在消息传输过程中丢失，您可能会在这些事件触发之前收到异常，因此请准备好忽略它们，以便事件可以清理。
除了从订阅者列表中删除客户端之外，其他清理工作完全取决于您的应用程序（即释放客户端连接时获取的资源）。我不知道需要进行任何其他清理。
Handling those events will keep your list of subscribers synchronized. It is indeed robust enough. Just remember that if a client drops during a transmission of a message, you might get an exception before those events fire, so be ready to ignore them so that the events can clean up.
Except for removing the client from he subscribers list, additional cleanup depends entirely on your application (i.e. freeing resources you acquired when the client connected). I am not aware of any other cleanup that is required.