I want to have multiple RPCs sent from a client to a server (in parallel). From the server side, I see that there can be only 1 outstanding request per client socket. Sure there can be multiple threads in the server, but each thread will service only 1 client socket at a time and that thread will run to completion on a pending RPC.
One way to get parallelism (from what I understand) is to open multiple Async Client connections from the client and send one parallel msg per connection. That way the number of connections that are opened, that many number of msgs can be processed in parallel (assuming that many threads are running on server). Is there any other way that I am missing? My use case looks like the following: client (1..N) ---> server ----> internal-server I want to maximize throughput and avoid delays. And I want to avoid clunky performance tuning of trying to figure out how many threads to run per client (which might not even be written by me) and how many to run in the server and how many to run in the internal-server. In some sense, I want to blast tens of RPCs from a client to a server and hundreds of RPCs from a server to internal-server and do it completely in an async manner. In other words, when Tserver processes RPC-1, the user code should be able to tell the server dispatcher that hold off....I'll call you back when I have all the data for the response (from internal-server). And then the server dispatcher goes off and processes RPC-2. When internal-server responds to a data-request, then that triggers server to call into the dispatcher asking it to transition RPC-1 from APP_WAIT to APP_RESUME. The thing is that this stuff is doable, if one keeps state of a RPC (which today we don't...for the most part). Is this on the roadmap? Or is what I want doable through some other means. Thanks Nitin
signature.asc
Description: Message signed with OpenPGP using GPGMail
