Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Preventing queuing of requests when all connections exhausted

On 2/3/2015 1:16 AM, Simone Bordet wrote:
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.
This is needed in case the destination is persistently slow (or hung). The delay could be in connection establishment, data transfer, or request processing.
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.
Correct.

I only care about the case of qx=0. I proposed an API that makes sense for other values of qx, but can tolerate an API where specifying qx=0 (or specifying qx=cx and enabling some other flag) invokes a special mode.
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
I can tolerate the failure being delayed by the time it takes to dispatch the request to a worker thread. Milliseconds, not seconds or hours.
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.
I believe I can tolerate spurious failures as long as the time window is reasonably short. Spurious queuing when it results in a request waiting twice the connection idle timeout much less so.
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 ?




Back to the top