> Are those buffers ever discarded? I guess it comes down to whether the > 8k buffer "belongs" to the connection or to the request. It looks like > the bug arises from the buffer being treated like it belongs to the > request when it really belongs to the connection. > > I agree, switching to a request-owned buffer strategy would certainly > increase the memory footprint since you'd need a buffer for each pending > request (which may be quite high when using NIO an/or async). Thanks for > clarifying that. > >> If the fairness becomes a practical problem, reducing >> maxKeepAliveRequests (100 by default) would force pipelining clients >> to the back of the queue regularly. > > How would this work, though? If the bug under discussion arises from a > connection essentially disconnecting one of these buffers from the > request whence it came, doesn't re-queuing the request re-introduce the bug? >
I was thinking of closing the connection (as maxKeepAliveRequests) does now. The re-connect would go to the back of the queue. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
