处理双工绑定 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
我做了一些测试,将处理程序附加到回调通道的 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.