Re: [jetty-users] Preventing queuing of requests when all connections ex

[Simone Bordet <sbordet@xxxxxxxxxxx>]

Hi,

On Sun, Feb 1, 2015 at 6:35 AM, John Gardiner Myers
<jgmyers@xxxxxxxxxxxxxx> wrote:
> On 1/31/15 3:16 PM, Simone Bordet wrote:
>>
>>
>>> My idea for an interface would be to exempt unused/idle
>>> MaxConnectionsPerDestination from the MaxRequestsQueuedPerDestination
>>> limit.
>>
>> Now I am confused. You said your case was for when all connections are in
>> use.
>> Why you want to exempt idle connections from a queue limit (which,
>> incidentally, is not even there) ?
>
> In my case, I do not want any requests to sit in HttpDestination.exchanges
> waiting for another, pending request to complete. If a request would have to
> wait for another request to complete before being started, then it should
> immediately fail, presumably with a RejectedExecutionException.
>
> An idle connection will soon pick up the request, as will a connection that
> does not exist but can be opened promptly.
>
> My proposal is to define HttpClient.maxRequestsQueuedPerDestination as the
> limit of requests per destination that are permitted to wait for another
> request to complete.

Let me rephrase it to see if I understand.

Let cx = maxConnectionsPerDestination, qx = maxRequestsQueuedPerDestination.

You propose to change the BlockingQueue capacity from qx to qx+cx.

This is needed in case a flow of requests arrives and establishing the
first connection is slow.
With qx=0 and cx=8, for example, I need to be able to queue at least 8
exchanges, and fail the 9th.
With qx=0 and cx=1, I basically only allow serialized requests.

Since now the queue capacity is larger than qx I cannot rely on the
queue to tell me if I have exceeded the queuing capacity.
I must now implement the limitation manually, along with the actual
connectionCount from the ConnectionPool.
That is, an exchange is allowed to be queued, if the already queued
exchanges are less than qx + cx - connectionCount

This may lead to spurious queuing or or spurious failures, as
connectionCount varies concurrently.
I'm not keen adding a synchronization point to handle the enqueuing precision.

For multiplexed destinations, the logic is the same, with the
connectionCount replaced by the inflight exchanges.

I may refactor the code to allow you to do all of the above, if the
spuriousness is something you can tolerate.
If so, please file an issue.

Other thoughts ?

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.