如何在启用会话的情况下处理 WCF 双工服务中的故障状态
我有一个启用了会话的双工 WCF 服务，并且我正在尝试避免客户端上的故障状态异常。
我发现了一些围绕此主题的讨论，但我发现的所有讨论都建议重新创建客户端代理或通道。非重点关注启用会话的双工服务。
我对这种方法的问题是，服务器中的每个客户端都有一个会话，并且每个客户端只有一个服务代理实例（单例服务代理）。由于它是双工的，因此在客户端，多个对象正在侦听该服务实例上的事件（从服务器发送到客户端的消息）。 如果服务处于故障状态，则无法再使用。如果我放弃该实例并创建一个新实例，我发现很难将所有事件处理程序再次连接到这个新实例。
我是否应该包装服务，并且每次对象挂接事件时，将处理程序存储在列表中（以便在重新创建服务时可以重新挂接它）？似乎丢失了代码，容易泄漏内存...
有没有办法只重新启动客户端代理/通道，而不丢弃所有代理实例？ （我正在使用 VS 生成的代理）
有什么想法吗？
谢谢， 人与生物圈
I have a duplex WCF service with sessions enabled, and I'm trying avoid fault state exceptions on the client.
I found several discussions arround this topic, but all I have found suggest to recreate the client proxy or channel. Non is focus in duplex services with session enabled.
My problem with that approach is that there is one session per client in the server, and each client has only one instance of the service proxy (singleton service proxy). Because it is duplex, in the client side several objects are listening to events on that service instance (messages sent from the server to the client).
If the service is in faulted state, it can not be used any more. If I discard that instance and create a new one, I'm finding it hard to hook up all the event handlers again to this new instance.
Should I wrap the service and every time an object hooks up for an event, store the handler in a list (so that I can re hook it when service is recreated)? Seems to be lost of code, easy to leak memory...
Is there a way to just restart the client proxy / channel, without discarding all the proxy instance? (I'm using the VS generated proxy)
Any ideas?
Thanks,
MAB
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您无法重新启动代理。从故障状态恢复的唯一方法是中止当前实例并重新创建新实例。在客户端，您必须正确取消注册依赖于代理实例的所有内容，创建新实例并再次注册所有内容。一旦您收到有关处于故障状态的通道的异常（=当您尝试调用服务时），整个操作就必须发生。休闲结束后，您必须再次致电服务人员。
在服务端，实例要么已经死亡（导致通道的故障状态），要么在会话超时后死亡。当您尝试回调故障通道时，还必须通过从已知客户端中删除该通道并取消注册任何依赖于该通道的内容来处理故障异常。
You cannot restart the proxy. The only recovery from faulted state is aborting current instance and recreating the new one. On the client side you must correctly unregister everything dependent on your proxy instance, create new instance and register everything again. This whole operation must happen once you get the exception about channel in faulted state (= when you try to call the service). After recreation you must call the service again.
On the service side the instance is either already dead (that caused the faulted state of the channel) or it will die after session timeout. You must also handle faulted exception when you try to callback on the faulted channel by removing the channel from your known clients and unregistering anything dependent on that channel.