Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
394 views
in Technique[技术] by (71.8m points)

.net - Handling dropped clients in a duplex binding WCF application

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:

  1. 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?
  2. 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

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...