"Receiver Loop" for named pipes is never started in a server process that uses only request handlers

[ogiesen]

I'm trying to use IRemoteRequestHandler<TRequest,TResponse> with named pipes between two processes on the same machine but I'm having no luck. As far as I can tell from debugging, the problem is that the NamedPipeWorker is never actually instantiated in the server process and thus the ReceiveLoop is never initiated and thus requests from the client are sent into nothingness and are awaited forever (the cancellation token passed to InvokeAsync() does not appear to be used - but that's a separate issue)...

It seems that all the samples for IRemoteRequestHandler that I've looked at probably only work because they have the client and the server classes both inside the same executable.. In that case the NamedPipeRemoteRequestHandler that gets called into life by injecting an IRemoteRequestHandler into a client class takes care of instantiating the worker - this doesn't have any effect however when the request handler class is in a different process. It seems that for remote request handlers, launching the receiver in the server process should probably be triggered by (auto-)registering an IAsyncRequestHandler or something like that, right?

P.S.: I haven't done any actual tests, but just from glancing at the code I suspect that the exact same problem would also apply to the TCP transport...

[neuecc]

Thanks, I will investigate it.

[Marbel]

Also have the problem with services.AddMessagePipeTcpInterprocessUds not creating the socket if i have two separately processes.
configure.HostAsServer is set to true in MessagePipeInterprocessOptions for the server/daemon process.
For test i invoked the IRemoteRequestHandler in the server/daemon process and the socket was created and was available for other clients.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.