Will a tomcat request connection also time out when a server side process is taking too long to send a response?
I have a spring boot application with an embedded tomcat server. To limit the impact of DOS attacks i've set the property server.tomcat.connection-timeout to 3 seconds. A connectionTimeout is the limit of time after which the server will automatically close the connection with the client. So if in my case the client takes more then 3 seconds to finish the request the connection will automatically time out. However, its not yet clear to me what exactly happens when instead it is a process on the server side that is causing a delay. To give an example, My web application is using a hikari connection pool that manages connections to the database. It can have a maximum of 10 database connections. If all 10 are in use any incoming request will have to wait for one of the database connections to become available. If this wait takes more then 3 seconds, will the tomcat connection time out? Or will the connection remain available since the delay isn't caused by the client? Thank you
According to the Tomcat 9.0 documentation, the connection-timeout is: The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. [...] Unless disableUploadTimeout is set to false, this timeout will also be used when reading the request body (if any). That is a time taken for the client to send the request. This is unrelated to the time that the server takes to respond to the request. So ... If this wait takes more then 3 seconds, will the tomcat connection time out? No, it won't1. In fact, it appears that Tomcat doesn't have any limits on how long a (synchronous) request may take to complete. Of course, the client could timeout a request if the server takes too long. It is unlikely that the server will notice this so that it can abandon the request. 1 - Assuming that the documentation is accurate. However, that config option has been present for a number of Tomcat versions, with the same description. If the documentation was wrong, this would surely have been noticed, reported and fixed.