Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Response timeout is harmful - remove it #1625
As described in this answer, when CherryPy raises a TimeoutError, it's doing so because the request took longer than the timeout to complete, but it was still allowed to complete.
The docs say:
Consider this script:
Run it with rwt:
Then time a request with curl:
The request takes the full 5 seconds to complete even though the timeout was set to 2 seconds. Additionally, the test will complete without timing out (in most cases) if the timeout_monitor frequency isn't increased.
If we were to believe the docs, the request would not be allowed to run longer than the timeout period, but it clearly is allowed to run to completion. Yet, even though it's allowed to run to completion, an error is returned, losing the value of the computation even if the client was still connected to receive it. According to the referenced SO answer, it's difficult if not impossible to interrupt a thread safely. Since the request has to be allowed to run to completion, the "timeout" functionality is not behaving as a timeout but is instead behaving as "make fail if slow". Such behavior should be optional and disabled by default if it's supplied at all.
The current implementation is misleading and causes harm.
Consider the condition where a user has just invoked a long-running request. They've left it to run to see if it will complete and are eager to see what the result is. The request runs for 10 minutes and finally completes, but when it does, the result is discarded and replaced with a timeout traceback.
Better would be for CherryPy docs to indicate that it cannot safely time out long-running requests and that requests that take too long should be managed out of process.
Hmm. I now see the docs also say:
Perhaps it could say "you must" instead of "you are free". But still, I'm struggling to think of a use-case where this timeout functionality is generally useful. Perhaps it would make sense for CherryPy to provide the timeout functionality, but it seems like it shouldn't throw away a response after it's been completed, even it exceeded the timeout to produce it.
I would like to solicit feedback to find out if this feature is used and useful by others.
Yes, I think it would be nice to have a timeout for generating responses, now that it seems it may be possible. It would be nice if such a feature could be implemented as a tool in a separate package (though I'm not sure if that's possible). I'd also like to see any timeout support be explicit about what the timeout or timeouts mean. Especially in a world with large and streaming responses, there's a big difference between a request that times out before the response is started and a request that times out mid-response (with the former being more useful in practice).