Hello,
I was looking at the way SolrJ (Solr's client library) is using Jetty to issue requests to Solr server (using Jetty server). As of now, Solr is using Jetty 9.4.48 in main (don't know if that's relevant to my question, unless behavior in this area recently changed).
From what I could see in the code and docs, the way Jetty client handles a new request to a particular destination is:
1. Add request to a queue
2. Attempt to get a connection from the pool
3. If successful getting a connection, use that to send the request, otherwise, just exit, something else will grab the request from the queue and send it when connections are available.
Caller is expected to provide listener(s) that will receive a callback for events happening in the request/response. Solr is using an "InputStreamResponseListener" like[1]:
InputStreamResponseListener listener = new InputStreamResponseListener();
req.send(listener);
Response response = listener.get(idleTimeout, TimeUnit.MILLISECONDS);
InputStream is = listener.getInputStream();
return processErrorsAndResponse(solrRequest, parser, response, is);
This pattern looks similar to what's in the Jetty docs, and even similar to what the blocking APIs in Jetty client itself are using.
The thread that sends the request (because it was successful acquiring the connection from the pool) will continue fetching requests from the queue and sending those for as long as there are requests in the queue. My question is, can't this be problematic as the queue grows? Can the thread that sends a request "FOO" be stuck sending other requests from the queue for longer than the request "FOO" takes to be processed on the server side, and a response is available on the client (at which point the listener.get(...) would return immediately).
Would it make more sense for the `send` to happen on the client's executor, something like?
httpClient.getExecutor().execute(() -> req.send(listener));
Thanks,
Tomás
