This issue was extremely difficult to trigger, typically resulting from the combination of:
Running a large number of blocking queries to an external data source. This is due to a quirk of the blocking implementation which will wait for the next request from the same client IP address before timing out the connection.
Running a large number of blocking queries to an external data source that happens to use the same hostname as the client IP address. This can be addressed by using a data source endpoint that does not use the hostname of the external server as a prefix, such as data source endpoints using the hostname of the server hosting the data source, or using aliases.
Large numbers of clients that share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.
Note that the issue is not present in Tomcat 9.0.x, 8.5.x, or previous releases.
Impacted configurations A blocking read or write operation on a data source (using a JDBC driver that supports it, such as MySQL) could be executed by a Tomcat process on an Http11Processor instance. A blocking read or write operation on a data source can be performed only by one process at a time, and so the blocking read or write operation would be performed by the process on the Http11Processor instance that happens to be executing the blocking operation.
Impacted applications These issues were
Steps to take to limit the impact of this issue
# Ensure that the blocking read or write operation on the data source is performed by the correct process.
If the blocking read or write operation must be performed by a Tomcat process, ensure that each Tomcat process is using an Http11Processor instance with an appropriate configuration to avoid this issue.
# Ensure that any Http11Processor instances used by your application have a suitable configuration, such as only accepting requests from one client IP address at a time.
Timeline
Published on: 09/28/2022 14:15:00 UTC
Last modified on: 11/10/2022 04:00:00 UTC