#8582 closed defect (fixed)
File "/usr/lib/python2.4/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address)
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.11.6 |
| Component: | web frontend | Version: | 0.11.5 |
| Severity: | minor | Keywords: | |
| Cc: | radek@… | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Hi,
I don't know why I'm getting those messages:(
Traceback (most recent call last):
File "/usr/lib/python2.4/SocketServer.py", line 463, in process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python2.4/SocketServer.py", line 254, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python2.4/SocketServer.py", line 521, in __init__
self.handle()
File "/usr/lib/python2.4/BaseHTTPServer.py", line 316, in handle
self.handle_one_request()
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/wsgi.py", line 184, in handle_one_request
gateway.run(self.server.application)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/wsgi.py", line 92, in run
response = application(self.environ, self._start_response)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/standalone.py", line 100, in __call__
return self.application(environ, start_response)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 414, in dispatch_request
return _dispatch_request(req, env, env_error)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 522, in _dispatch_request
req.send_error(exc_info, status=500, env=env, data=data)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/api.py", line 396, in send_error
exc_info)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 444, in _dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/main.py", line 229, in dispatch
req.send(output, content_type or 'text/html')
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/api.py", line 359, in send
self.write(content)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/api.py", line 463, in write
self._write(data)
File "/usr/lib/python2.4/site-packages/Trac-0.11.5-py2.4.egg/trac/web/wsgi.py", line 212, in _write
self.handler.wfile.write(data)
File "/usr/lib/python2.4/socket.py", line 256, in write
self.flush()
File "/usr/lib/python2.4/socket.py", line 243, in flush
self._sock.sendall(buffer)
error: (32, 'Broken pipe')
Could somebody help me?
System Information:
CentOS: 5.3 Trac: 0.11.5 Python: 2.4.3 (#1, Jul 27 2009, 17:57:39) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] setuptools: 0.6c9 SQLite: 3.3.6 pysqlite: 1.1.7 Genshi: 0.5.1 Agilo: 1.0.1-PRO Subversion: 1.4.2 (r22196) jQuery: 1.2.6
Attachments (1)
Change History (9)
comment:1 by , 15 years ago
follow-up: 3 comment:2 by , 15 years ago
| Component: | general → web frontend |
|---|---|
| Keywords: | File "/usr/lib/python2.4/SocketServer.py" line 463 in process_request_thread self.finish_request(request client_address) removed |
| Milestone: | → 0.12.1 |
| Severity: | normal → minor |
Nothing critical here, it's just the client closing the connection and the server noticing this.
We used to hide that traceback (#1183), but it keeps reappearing ;-)
comment:3 by , 15 years ago
comment:4 by , 15 years ago
| Milestone: | 0.12.1 → 0.11.6 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Should be fixed by r8485.
comment:5 by , 15 years ago
| Owner: | set to |
|---|
comment:6 by , 15 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Follow-up needed, as now a lenghty operation won't abort on the server if the client cancels the request…
comment:7 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Oh well, that was actually never the case, it's just that it's disturbing now to not see those tracebacks ;-)
So I'm closing again.
OTOH, it would be really nice to have a way to poll the client earlier and detect whether the connection is still alive, during the processing of lengthy request, in order to avoid putting some load on the server when there's no one listening at the other end ;-)
So I tried various hacks, and it seems that using 100-Continue could work, although taking some liberties with the HTTP/1.1 protocol:
- per rfc:2616#section-10.1.1 100 Continue, all seems fine with this method:
The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response.
- per rfc:2616#section-8.2.3, Use of the 100 (Continue) Status, 2nd server requirement says:
An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation
Well, it's only a SHOULD NOT ;-)
The advantage of this is that we could have some req.check_connection() call in some of the most resource intensive loops which could interrupt the processing if the client disconnected.
Doing so certainly break the WSGI way of things, so I'm not sure it's even possible to implement that for mod_wsgi, for example.
by , 15 years ago
| Attachment: | t8582-100-Continue-wsgi-proof-of-concept-r8488.diff added |
|---|
proof of concept, works well with tracd
Replying to radek@…:
I see that messages appear when I am clicking rapidly between menu tabs.