I have some remoting code, using IPC Channels, and I'm seeing weird
behavior.
I have a server process that comes up and creates an IPC Channel, and I
have some client proxies to objects in that server. The server side
objects are registered as singletons, and are created on the client by
Activator.GetObject via uri like "ipc://channel_name/Foobar".
I have code that detects if the server has gone down, and if so,
attempts to relaunch the server. When this happens, the server gets an
Access Denied remoting exception when trying to create the IPC Channel,
because the named pipe still exists, because the client still has a
handle to it (even though all client side proxies are out of scope/null
etc).
What I'm seeing is this:
The client process still has a handle to the named pipe (which I can
see in SysInternal's Process Explorer). What appears to be the case is
that the client side of the remoting hasn't shutdown it's end of the
pipe, so the server can't recreate it.
The way I've worked around this is to null out all references to the
client proxies on the client side (which is easy in my architecture)
and then force a Garbage Collection! This seems like pure evil and is
really not something I'd like to do, I'd rather do something
(notionally) like ClientChannel.Dispose or whatnot, to get client to
close the pipe.
I've looked through the ChannelManager, and looked around at
IpcChannel, IpcClientChannel, IpcServerChannnel, but I can't seem to
find a way to close the client side of the channel down. Is there a
way to do this?
Basically, when does the client side close the pipe, and can I force
this behavior?
|