Bugs item #1063924, was opened at 2004-11-10 08:27
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Florent Guillaume (efge)
Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore should handle ECONNRESET in send
Initial Comment:
asyncore.dispatcher.send doesn't handle ECONNRESET,
whereas recv correctly does.
When such an error occurs, Zope displays for instance:
ERROR(200) ZServer uncaptured python exception, closing
channel <ZServer.HTTPServer.zhttp_channel connected
x.x.x.x:33054 at 0x4608ac2c channel#: 50679 requests:>
(socket.error:(104, 'Connection reset by peer')
[/usr/local/lib/python2.3/asynchat.py|initiate_send|218]
[/usr/local/zope/2.7.2/lib/python/ZServer/medusa/http_server.py|send|417]
[/usr/local/lib/python2.3/asyncore.py|send|337])
zhttp_channel is just a subclass of http_channel.
The exception is raised by asyncore itself when it
receives the unhandled error.
A proposed fix would be to do the same kind of handling
than is done in recv, but I don't know enough about
asyncore to know if it's correct
----------------------------------------------------------------------
>Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-06 21:49
Message:
Logged In: YES
user_id=341410
Originator: NO
It would seem to me that a connection where sending raises ECONNRESET,
ENOTCONN, or ESHUTDOWN, should be closed, as is the case in recv.
However, generally send is usually called before recv, so if we close the
connection in send, then recv won't get called. In basically all cases, we
want recv() to be called so that we get data from the buffers if possible.
Usually if there is data in the buffers, an exception won't be raised, so
we wouldn't close the connection until the next pass.
If we make a change at all, I would change send() to:
def send(self, data):
try:
result = self.socket.send(data)
return result
except socket.error, why:
if why[0] == EWOULDBLOCK:
return 0
elif why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]:
return 0
else:
raise
I have not yet tested the behavior in Python 2.5 yet, as the test cases
for Python 2.5 asyncore are basically nonexistent. If we added portions of
the test cases provided in patch #909005, we could more easily test these
kinds of things.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063924&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
