On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz <ch...@christopherschultz.net> 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
