Hi Ben, If I understand your question, you are asking if it is possible to decouple or pipeline the sending of the request and the reading of the response. E.g. do something like send(req1) send(req2) recv(resp1) recv(resp2) I think your question is, if I do this how do I know what response goes to what request.
The answer is that the server guarantees in-order processing of requests on a given connection. So correlating requests to responses can be done by keeping a queue of as-yet unanswered requests. In 0.8 we also added an official correlation id (an integer field you can set that the server passes back unchanged in the response. This is meant to help do tracing across client and server and may help to debug your implementation. We do not currently send back the API key since there is only one correct value that could have--whatever the api of the corresponding request was. One caveat is that the server doesn't really fully pipeline request processing at this time so if you do pipeline you may not get quite as much parallelism as you expect (you can never get full parallelism because of the ordering guarantee). But in the current code until a response is sent for req1 the server won't start reading req2. This is not hard to fix and we will get to it in the next major release I think. -Jay On Thu, Dec 6, 2012 at 7:50 AM, ben fleis <b...@monkey.org> wrote: > I just realized something important. The BoundedByteBufferSend comment > above is not in sync with my original question. I was asking about > Responses -- meaning, can I multiplex off a single socket, and when reading > an arbitrary response, switch on request_id to the right handler? > > In the blocking console sync client (which is the only trivial way to > follow the code that I've found -- please enlighten if there's an async > thing I can easily trace), this is a non issue, since you request, wait, > parse expected response. > > Or do I need instead to just open separate sockets? (Not a big deal, but > nice to understand clearly.) > > ben >
