On Tue, Dec 10, 2019 at 4:36 PM Mark Thomas <ma...@apache.org> wrote:
> On 10/12/2019 14:27, Christopher Schultz wrote: > > <snip/> > > > Would using org.apache.catalina.connector.RECYCLE_FACADES=true have > > made this problem go away? Or would the behavior have been the same, > > just less dangerous? > > I think it would have triggered some NPEs in the background thread. > > > I'm wondering if Tomcat could or should have another safety feature to > > help catch this sort of thing in development. In all my development > > environments, I have the JDBC connection pool size set to a fixed > > maximum of 1 connection. This means that any potential deadlocks in > > the application due to sloppy connection-management will cause pretty > > early because we'll get pool-fetch timeouts, missing-return-connection > > errors, etc. > > > > Request object reuse has a measurable positive effect on performance > > in production, > > It would be worth confirming that is still the case for the Request and > Response objects. I suspect it is but it would be good to get some > recent, hard data. > It would generate more GC per request and it is measurably slower on a best case scenario with a static file (the worst would be starting to use charsets and char input/output, or "large" Servlet buffers - the default is 8KB but people often increase it). Quick test: add request = null; line 305 of CoyoteAdapter. -10% with ab -k on tomcat.gif > > > but in development probably doesn't matter quite so > > much. In the same way that WebappClassLoader becomes inert when the > > application has been stopped, perhaps we could "shut-down" request / > > response / session objects that have been loaned to a > > request-processor thread. > > > > Something like this: > > I'm not sure why we need this over and above the RequestFacade object. > Rémy
