Ticket #853 (defect)
Opened 4 months ago
Last modified 1 month ago
consistent time out of the WSGI server
Status: new
| Reported by: | lawouach | Assigned to: | fumanchu |
|---|---|---|---|
| Priority: | high | Milestone: | 3.2 |
| Component: | wsgiserver | Keywords: | |
| Cc: | davidf@sjsoft.com |
It appears that the fix for #810 has a collateral effect of consistent and rather unexpected 408 response due to time out. I wonder whether or not the fix is the wrong one.
Change History
09/21/08 16:33:38: Modified by stefan_betz@gmx.net
09/27/08 22:56:31: Modified by fumanchu
I can't see how the code before the fix would have done anything in the same situation except drop the conn, which hardly seems better. IMO the new code simply exposes flaws a little more. Perhaps we should increase the default socket_timeout? Apache waits 300 seconds by default (although that's during a request; its KeepAliveTimeout?, the time allowed between requests, is only 5 seconds).
10/03/08 07:24:09: Modified by lawouach
I can't see why either to be honest. That being said, I do not use CP behind any webserver and I had constant time out errors with httplib2. Commenting the lines in wsgiserver fixed the behavior.
11/24/08 12:17:50: Modified by davidf@sjsoft.com
- cc set to davidf@sjsoft.com.
We've had exactly this problem on multiple sites running Windows and CherryPy's wsgi server. Reverting r1971 effectively fixed this (it was consistently reproducible before). At the moment we're having to deploy our own patched build of CherryPy to avoid it...
11/26/08 07:51:03: Modified by lawouach
Robert, I've been through the code of the socket module [1] and it seems the timeout state is revealed by the polling sub-system (poll or select). However it isn't clear what can trigger such error in the underneath stack.
A few notes however:
- I don't recall any declared or suggested bugs of a time out nature prior to rev 1971.
- Line 135 of the wsgiserver indicates we wanted to silent the "timed out" error since (that line has been there for a long time).
Now to be fair I can understand the point of #810 but it appears the fix might not be the proper one and we need to revert it.
11/27/08 23:34:03: Modified by fumanchu
Agreed. AFAICT Apache doesn't ever emit 408 either; it appears to just drop the conn. Feel free to revert [1971] (but try to replace the test with the new behavior).


Works for me with Apache 2.2 on a Debian Etch Machine! Is this a Problem in the Keepalive Handling of the Python socket Module?
mfg Betz Stefan