In part 4-7, I essentially discussed what the timeout value should be. As guidance:
- The timeout should not be triggered prematurely
- You should consider if the timeout should have a buffer to allow the slowest resource call to complete
In this blog post, I would like to continue the timeout parameters discussion.
Decrease timeouts progressively as you move downstream: What do I mean by that? As I mentioned in part 4-6, a software solution will have many timeout parameters specified in all layers of the solution; middleware, database, network, operating system, etc. As a request travels through the solution, it will engage resources where timeout defaults exist. Suppose the first resource (for example a load balancer) the request hits has a timeout configured to be 10 seconds, and the last resource (for example a database) has a timeout of 20 seconds. If the request is running for longer than 10 seconds at the database, the load balancer timeout is triggered potentially leaving the request executing at the database. In this case, the timeout parameters should be set in a way that the downstream system should always have a lower timeout value. This leads to a more graceful resource management that should happen when one or more components of a solution stack is slow.
A note worth mentioning here is that the default timeout values for many of a solution layers are typically large. This allows requests not to time out prematurely. However, when these timeout values are considered in the context of the end-to-end request flows, you will find that the timeout values should be adjusted for compliance with the recommendation discussed here. For example, the default query timeout defined on a JDBC data source in WebSphere Application Server (WAS) is not set. This means that all SQL statements using this data source will not be timed out by WAS no matter how long they execute in the database. This query timeout is really a JDBC driver property which WAS exposes to allow the flexibility for setting this timeout value. When this timeout is set, WAS will pass to the JDBC driver this timeout value to be applied for all SQL statements using the corresponding JDBC data source. Interestingly, suppose the query timeout in WAS is defined to be at 5 seconds, but a SQL statement may run in the database for much longer than that. When the timeout is triggered by the JDBC driver, the driver tells the database to cancel the SQL statement. This behavior is only true for the latest versions of certain database. For example, the latest versions of DB2 and Oracle database provide this behavior. In the older versions of such databases, timing out a SQL statement by the driver does not cancel the SQL statements in the database.
The point made in the previous paragraph should alert you to be careful when modifying the timeout parameters.