tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Whittington <>
Subject Re: bindOnInit and maxConnections for AJP connectors
Date Fri, 08 Apr 2011 08:50:21 GMT
On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz
<> wrote:
> Mark,
> I understand that a fix has already been applied, but...
> On 4/6/2011 7:16 AM, Mark Thomas wrote:
>> I thought of two options for issue 3:
>> a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket
>> and don't recycle it until the socket is closed.
>> - Increases memory requirements.
>> - Fixes issue 3
>> - Retains current request processing order.
>> b) Check the input buffer at the end of the loop in
>> Http11Processor#process() and process the next request if there is any
>> data in the input buffer.
>> - No Increase in memory requirements.
>> - Fixes issue 3
>> - Pipelined requests will get processed earlier (before they would have
>> been placed at the back of the request processing queue)
>> I think option b) is the way to go to fix issue
> What about a third option that is essentially (a) except that you trim
> the input buffer and discard the already-processed request(s) from it.
> The input buffer stays bound to the request and continues where it
> left-off when another request processor becomes available.
> That would maintain scheduling fairness and hopefully not require much
> in the way of memory usage. Since pipelining requests with entities is
> not a good idea, the chances of getting a large amount of data in the
> input buffer is relatively low. There's also a limit on the size of that
> buffer, too.
> Would that still represent too large of a memory requirement?

The input buffer is 8k by default (max header size), so this could be
significant with a large maxConnections.
Pruning the buffers to retain only required space would generate a lot
of garbage, so probably not a good option either.
If the fairness becomes a practical problem, reducing
maxKeepAliveRequests (100 by default) would force pipelining clients
to the back of the queue regularly.

We could go with option a) and use the processor cache size to bound
the 'memory vs fairness tradeoff' - e.g. place pipeline connections
back on the queue, but add their processor to a 'borrowed' queue
without recycling. If the total processor limit is met and the
recycled processor cache is exhausted, then a borrowed processor is
recalled, the pipelined connection drained, and the processor then
made available for use.
The default processorCache is 200 (matches maxThreads), so default
behaviour would be unfair.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message