On 06/07/2011 08:55, Konstantin Kolinko wrote: > I have doubts regarding this change. > > If I understand correctly, recycle() (and thus recycleInternal()) is > not called when several requests are processed in a row.
Recycle is called between every request, keeping in mind that a Comet request may involve multiple reads and writes and that Async requests may have multiple writes. The call is triggered in the Handler implementations in the protocol. - Http11Protocol: Http11ConnectionHandler#process() calls processor.recycle() unless the socket is in long poll mode (i.e. the request is ongoing) - Http11NioProtocol: Http11ConnectionHandler#process() calls release) (which in turn calls processor.recycle()) unless the socket is in long poll mode (i.e. the request is ongoing) - Http11AprProtocol: Http11ConnectionHandler#process() calls processor.recycle() unless the socket is in long poll mode (i.e. the request is ongoing) The calls to recycle were somewhat randomly spread about the code for different connectors and there were certainly bugs in the past where a particular code path could bypass all the recycle calls. One of the benefits of the recent refactoring is that it is much easier to check that things are correct and also easier to fix when they are not. One of the things at the back of my mind when doing the refactoring was cleaning up the recycle calls. I didn't do it explicitly but it looks like it has happened anyway as a side-effect of aligning the code. The only minor issue I can see are some unnecessary calls to recycle in Http11Processor#process(). > So, in the old code sendfile is set to null before each request, in > the new code it is set to null only once after connection is closed. I don't think so. If you have some analysis that suggests otherwise, please share it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
