-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 12/10/19 10:36, Mark Thomas 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.
> 
>> 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.

The RequestFacade is intended to protect the container from the
application, right? And they are (usually) re-used. If a RequestFacade
object is retained by the application and used later, a later
client-request may be confused with the one the application was expectin
g.

In the solution I presented, the facades are one-time use and will
stay dead once they are killed. The application can't make a mistake
and read a later client-request or write to a later client-response.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3xKskACgkQHPApP6U8
pFhZyBAAtLxars/ZWmm5pRUkAg4yamIGLOflCBWE38j01NzGVmfibczkToyOkrIX
qLRSzlLWQsX3x3559I5gD5o9KAwixBCO0M+oCCGzOAmnnmXVs7dPvTnLYJKrJMW0
U811tR9cNpNAN+rrdLhafYe+O8gHNsbuAOwLOnePc3lt/Q1ze7/kNYLsKDnrt8GG
lQKLE5Tv6mYr6tDnio9I9GjYnXP+G4swSvIL74o4swhzTLG5dzMAELOWtvBTBlPR
MoZvM6T1vIizhYf8xMMOCJuyMVxHm4kbesAlgAVdaff1pCqf9UjezrM/j+g7H0m9
5t6bC13EB/uKKGvz6sb1zJHr3yPiX+KRdiRaL59X96oMlKEZhBlySD1fk7KldU6W
62N9u6l+TrrGG3aKOrIEPYLdIsMNrbPlPDirissnCygkFPMDRKNOjH9xs5CZqV1G
aXI45uC9gUtC4wCdNnSYE+f+uosDdY7WYTWdru0GuDDod/iOOOxNfPbJAyqE8t1w
G8KF+22rJvVxmehd78UL2LQtsYeOjLsZ2HJQAa7LwRZN+TCRhv2efJMIWncPbRuP
GjVxnoRBrkvFSnGNoP2ZKqP0lN7Jrf470NWr4wQHD1r1P5p8Z4suilViS77gxpSK
LQlO+bpl08BrOMY4f7+oRjeLA0FhwA8rNNc7LeTdxmud0LPN9Ro=
=gHas
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to