thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Bahadur <nit...@gmail.com>
Subject Query on async server processing
Date Thu, 19 Sep 2013 07:33:31 GMT

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


Mime
View raw message