If the code below actually compiles (I didn't try it or look at the docs), that must mean that OperationContext.Current.Channel supports a Closing event for every type of channel (not just a callback channel). The fact that it might not fire reliably for every close-cause and/or for every channel-type is not particularly important to your code's proper operation -- you still need to trap exceptions from both Begin & End actions.
The reason is that it's always possible that your process (or thread) will have its time slice end immediately after your code gets a "channel is still open" response from any arbitrary test. The next statement, calling either BeginX or EndX (or anything else that presumes that the channel is still open), still could bump into a closed channel. (AFAIK, MSMQ handles all these cases internally, without ever signalling an error if the other end of the queue isn't up and running.) At 03:36 AM 7/25/2006, Ragnvald Barth wrote (in part) >So, when Indigo knows in advance that B is down, there must be a way that >my application code can detect it as well. > >And it is: If the connection between A and B is a callback channel, I can do >the following: > >OperationContext.Current.Channel.Closing += new >EventHandler(OnConnectionClosing); > >and thereby detect when the connection is closing! > >What I need to solve my problem is a way to detect that the connection is >Closing also when it is not a callback channel. Can anyone help? J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
