[C# / Win] Staying async with CallInvoker or using resolver plugin

[falco...@gmail.com]

I have a problem right now. I am developing somewith for windows with GRPC for C#. For that, I need name resolution in my GRPC application. To make it easy, the name server is also part of one instance of the program and implemented as GRPC service. So the application is mostly a container for GRPC services.

The channels should be resolved on the first RPC call. Therefore, I wanted to solve this by implementing a CallInvoker (since clients all can get Channel or CallInvoker, and Channel doesn't allow this kind of modification). My CallInvoker basically calls the ResolveName method from my GRPC name service in the CreateCall method. Sounds easy, but the problem is, that since my GRPC services are using that, this could be run from a GRPC thread (CompletionQueue). So to avoid the problems I had with https://github.com/grpc/grpc/issues/6948 I would have to call it async. But CallInvoker does not allow to run anything async, since all the Task stuff is done deeper in AsyncCall. And if I use Task.Run to make the call asynchronous in a worker thread, this works only for one level. In the next level, it would get stuck...

The best would be to avoid the CallInvoker all together and just use a resolver plugin as described in https://github.com/grpc/grpc/blob/master/doc/naming.md but it seems that the C# library is not supporting it, and my workaround is also not working reliable.

Any ideas on getting a resolver plugin to work with C# or to fix using GRPC calls in CallInvoker?

[falco...@gmail.com]

The only possible workaround right now is to make the name server a separate application with own process id. Then, it does not use the shared GRPC thread pool and is not getting stuck. That's ok for progressing in development, but not a viable final solution.

[falco...@gmail.com]

I cleaned the question up a bit and created a issue. https://github.com/grpc/grpc/issues/11843

Crosslinking to avoid duplication and confusion.