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? -chris
signature.asc
Description: OpenPGP digital signature
