Hi Simone,
IN our case, since we use Jetty 9.3.x and use the HttpClientTransportOverHTTP2 mechanism to perform HTTP/2 communication. Also in this case, we would open just 1 TCP connection (as the connection pooling support for HTTP/2 is only available in Jetty 9.4.x). Now, Jetty starts rejecting requests in case the number exceeds the maxRequestsQueuedPerDestination. For a use case wherein we send bulk requests in a tight loop, we should never exceed this number and so to avoid that, we set the Semaphore on maxRequestsQueuedPerDestination. Obviously, if the server has high bandwidth and processing at a high rate, we would effectively not be queuing up requests, and processing them as requests are made. Just to pint out, our use case executes around 10000 HTTP/2 requests per second.
Also, the reason why we treat sync and async differently is that for async requests, we just send them and forget. We have application specific listeners hooked to Jetty listeners that invoke the call back functionality once the request is processed. For sync requests, the caller is blocked waiting for a response, and we cannot have the caller wait indefinitely. For this reason, we have imposed a timeout so as to process and return the response within the specified time.
Thanks
Neha