Question:
How have people implemented .NET Remoting connection recovery? Is there an
approach easier or better than mine?
Details:
For some APIs such as ADO.NET one can effect connection retry/recovery by
making a thin wrapper around the apis that go over the wire. For example,
with ADO.NET you can wrap the IDbConnection.ExecuteXxx family of methods.
However, with Remoting invocations are sprinkled around the code so that
it is hard provide a system level wrapper methods. Since an architect does
not want to enforce that every call to a remoted object be wrapped by some
ugly retry try/catch block, what's thet best way to provide connnection
retry/recovery?
Proposed approach:
I used an IMessageSink implemented from a IClientChannelSinkProvider
implementation. My ChannelSinkProvider and MessageSink expose an event
that is raised when the return IMessage (a ReturnMessage) has an Exception
that indicates a bad connection. Event delegates can determine if the
message should be resent.
Approach Details:
I noticed that HttpChannel (and presumably TcpChannel) already attempt to
reconnect several times if one cannot be made, so an automatic retry is
not necessary. In addition to allowing a "manual" retry, I have shown that
I can do a redirection to another host or port by chaning the
IMessage.Properties["__Uri"] message property. I have not proved that I
could also change the channel and formatter by setting up a new channel
stack and redirecting to that stack. Among the questions here is will my
Proxy decide it's dead if it's channel is unregistered and can I access
IMessageSink.SyncProcessChannel/AsyncProcessChannel directly or somehow
create a surrogate Proxy on the new channel.
That approach would look like this:
OldProxy -> RobustMessageSink -//-> Old Sink Chain
\
-> NewProxy -> New Sink Chain
The goal of this exercise it so that the consumer of OldProxy does not
need to do drop OldProxy and Make NewProxy for every method call.
Kenneth Brubaker, President
Just In Time Consulting Services, Inc.
