Run mutiple Async grpc server instance based on the same server code: Only the first instance could responce clients.

[SallyTYT]

My application requires running multiple async grpc service instances based on the same server code. These instances will be mounted on different network ports. But only the first instance could work.

To verify this issue, I tested using the helloworld example, as shown below figure. I changed the service to "async", and duplicated the run server vi, then running the 2 server on 50051 and 50052 ports. It turns out the same as my application -- 50051 server worked, which is the first instance running. And 50052 server couldn't work, the client was stuck in "Client Unary Call.vim". If I changed the running order, still only the first server instance could work.

While if the service is changed to "sync", both server instances could work.

Is this an expected behavior?

Thanks,
Yongtao Tan

AB#2468334

[kt-jplotzke]

I've found that the re-entrancy settings for the default created async RPC methods are set to non-reentrant execution. To have multiple server instances, you must set each of these VIs to 'Shared Reentrant Execution'.

Likely this should changed in the template VIs. (I can only confirm that this is the case for v0.5.1.2 right now; perhaps this is already updated in a later version)

[SallyTYT]

Thank you @kt-jplotzke , problem solved

[Rohith-Grandhi]

@ni-sujain, can we make the same change in the master as suggested in this issue? do you foresee any implications if we do this change?

[sujain-git]

@Rohith-Grandhi The suggested fix(while it improves the behavior) might not be enough for certain use cases. Async RPC workflows may not work properly because of several issues related to how its being implemented. One of those implementation issue is 'Re-entrant VI setting' on the generated VI. We have some plans to fix Async RPCs in future. That will include the suggested fix as well. Meanwhile a quick trial-error fix can be done locally at the user end just to check if it suffices for their use case but we are not fixing this in the main branch right now.