[PATCH] tracd regularly shows timeout exceptions with full traceback

[pipern]

This appears related to #1183, but as that's been closed a while I thought to create a new ticket.

We regularly get these exceptions thrown by tracd:

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 54647)
Traceback (most recent call last):
  File "/usr/lib/python2.5/SocketServer.py", line 464, in process_request_thread
    self.finish_request(request, client_address)
  File "/usr/lib/python2.5/SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.5/SocketServer.py", line 522, in __init__
    self.handle()
  File "/usr/lib/python2.5/BaseHTTPServer.py", line 318, in handle
    self.handle_one_request()
  File "/..../trac/trac/web/wsgi.py", line 179, in handle_one_request
    environ = self.setup_environ()
  File "/..../trac/trac/web/wsgi.py", line 129, in setup_environ
    self.raw_requestline = self.rfile.readline()
  File "/usr/lib/python2.5/socket.py", line 381, in readline
    data = self._sock.recv(self._rbufsize)
timeout: timed out
----------------------------------------

This is at the Trac trunk at r9337.

Trac appears to be working normally, but a few moments after the page is loaded in the browser, one or more of these exceptions appears. This is with several different browsers, but I personally use Firefox 3.0.x and 3.5.x.

I use Debian, and 2.5.5.

I have applied the attached patch to our local installation to resolve this.

[pipern]

Catch and handle socket.timeout exception that setup_environ() can throw when HTTP client is inactive

[cboos]

I don't think those timeouts are normal, therefore silencing the exception doesn't feel right.
You should rather try to figure out for which requests tracd is timing out, and why. You could use Firebug to see what happens in more details, or even set up a TCP tunnel using e.g. NetTool.

[pipern]

Thanks for your advice, we shall investigate further.

[pipern]

This appears to have been applied (to a slightly different place) in [9342]

[cboos]

Well, the socket.timeout exception as such is still not trapped, but no one else has reported a problem with that...

If someone can demonstrate this is a real and reproducible issue, please reopen.