Tomcat Request Timeout

Tomcat request timeout

With Tomcat 7, you can add the StuckThreadDetectionValve which will enable you to identify threads that are "stuck". You can set-up the valve in the Context element of the applications where you want to do detecting:

<Context ...>
  ...
  <Valve 
    className="org.apache.catalina.valves.StuckThreadDetectionValve"
    threshold="60" />
  ...
</Context>

This would write a WARN entry into the tomcat log for any thread that takes longer than 60 seconds, which would enable you to identify the applications and ban them because they are faulty.

Based on the source code you may be able to write your own valve that attempts to stop the thread, however this would have knock on effects on the thread pool and there is no reliable way of stopping a thread in Java without the cooperation of that thread...

Will a tomcat request connection also time out when a server side process is taking too long to send a response?

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't¹. 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.}

SpringBoot: server.tomcat.connection-timeout NOT WORKING

There is no setting in Spring MVC to control the timeout of request handled by Controller unless of-course you are using Async processing which basically means you need to return a Callable<> if you want spring.mvc.async.request-timeout to work. The property you are mentioning server.tomcat.connection-timeout is actually a tomcat property ( which is set up by Spring Boot) which basically refers to timeout if the client opens a connection but is not sending or it's very slow to send the request ( uri, headers etc. as per http protocol)

The number of milliseconds this Connector will wait, after accepting a
connection, for the request URI line to be presented. Use a value of
-1 to indicate no (i.e. infinite) timeout.

You can check this for an issue reported in Spring Boot and the comments by Spring team.

Tomcat: Setting connectionTimeout in server.xml not effective

I'm not sure what you're trying to do exactly. It seems like you want to set a timeout on the time it takes your server to reply to a request.

So what roughly happens:

1. Browser sets up TCP connection with your server
2. Browser sends html request
3. Your server receives the request and starts processing it
4. Your server starts sending a response
5. Your server finishes sending a response

As far as I know, connectiontimeout is what happens between point 1 and 2 (again, roughly, the details are slightly more complicated). So the response time of your server does not matter here. It's only the time between when the browser sets up a connection with your server and when it sends the request. So if you want something based on your server response time, you are not using the right attribute.

Now, usually, people don't really set timeouts on responses, but the consumer (in this case the browser) sets the timeout. My browser, for example, sets a timeout of 300 seconds. I've looked around in the documentation a bit, and you might be able to set a replytimeout on the workers, but I haven't tested this and I'm not sure it will work.

More to the point, why do you want to set a timeout on the response? Is there some call (database, webservice, ...) you make while processing the request that could take very long? In that case, you should just set a timeout on that call. This will allow you to log an error and just instantly give the 500 error. If you just happen to be processing forever, you probably want to interrupt and stop the process and return an error and again potentially log information so you know where it's going wrong. In conclusion, control waiting on feedback from external resources and your processing time in your web application instead of trying to set a reponse timeout on your web server.

Meaning of connectionTimeout in tomcat

Taken from here: https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

connectionTimeout

The number of milliseconds this Connector will wait, after accepting a
connection, for the request URI line to be presented. Use a value of
-1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships
with Tomcat sets this to 20000 (i.e. 20 seconds). Unless
disableUploadTimeout is set to false, this timeout will also be used
when reading the request body (if any).

Increasing connection timeout for Tomcat in Spring Boot

As per comments from Rcordoval -

Check this property: spring.mvc.async.request-timeout= # Amount of
time before asynchronous request handling times out

This setting helps with rest of gatling configurations

spring.mvc.async.request-timeout=1200000

The root cause however is that when requests come in large numbers, then all worker threads (200) get occupied in uploading open connections (2000) (the Controller is taking MultipartFile as argument and returning a DeferredResult )

I think DeferredResult shines when request serve logic is fast and business logic is slow (runs on forkjoin.commonPool). It does not quite fits with MultiPartFile uploads (blocking and slow) and more so when File sizes are big since then responses are not quickly resumed (as can be seen in above response per sec chart, only after few seconds responses start resuming since open connections are 2000 and workers only 200). If workers are increased, it then mitigates advantages of async processing anyway.

In this case, request processing (upload and blocking) was slow and business logic was fast. so responses were getting ready but all the worker threads (200) are so busy serving more and more requests that responses are not getting resumed and timing out as a result.

Probably makes a case for having separate pool for request serve and response resume in async processing with DeferredResult ?

---

Related Topics