Hi, On Sun, Feb 1, 2015 at 6:35 AM, John Gardiner Myers <[email protected]> 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. _______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
