New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppress [Errno 10053] errors (Windows) #999

wants to merge 1 commit into
base: master


None yet
2 participants

jan11011977 commented Jul 21, 2017

This prevents pywsgi from printing stack traces when the client disconnects from the server.

When running pywsgi on Windows I am seeing a lot of these stack traces:

File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 935, in handle_one_response
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\geventwebsocket\", line 87, in run_application
    return super(WebSocketHandler, self).run_application()
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 909, in run_application
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 895, in process_result
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 741, in write
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 763, in _write_with_headers
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 726, in _write
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 701, in _sendall
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 419, in sendall
    timeleft = self.__send_chunk(chunk, flags, timeleft, end)
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 355, in __send_chunk
    data_sent += self.send(chunk, flags)
  File "c:\virtualenv\compass\2017-07-20T00.23.18\lib\site-packages\gevent\", line 323, in send
    return sock.send(data, flags)
error: [Errno 10053] An established connection was aborted by the software in your host machine
Thu Jul 20 11:02:00 2017 {'REMOTE_PORT': '58259', 'HTTP_HOST': 'shg-compass', 'REMOTE_ADDR': '', (hidden keys: 33)} failed with error

I can see that we are already suppressing EPIPE and ECONNRESET errors, but on Windows there is also the WSAECONNABORTED which needs to be suppressed.


Suppress [Errno 10053] errors (Windows)
This prevents pywsgi from printing stack traces when the client disconnects from the server.

This comment has been minimized.


jamadden commented Jul 21, 2017

The reason that we feel good about swallowing EPIPE and ECONNRESET is that they're usually caused by the remote machine hanging up, i.e., the client timed out and quit, or lost its connection, or whatever. But the error message here ("connection was aborted by the software in your host machine") seems to suggest that it's the local machine/process that's at fault, which sounds very different and more concerning to me---I would want to see if there was something I needed to adjust locally to stop those errors.

Then there's the fact that the WSA stuff isn't defined outside of Windows, hence all the Travis test failures. Checking for it would need to be made conditional. One way to do it would be with getattr(errno, 'WSAwhatever', errno.EPIPE), but that's ugly and perpetuates hard-coding of this growing list.

Instead we could use a value on self:

class Server(object):
    swallowed_connection_abort_errnos = (errno.EPIPE, errno.ECONNRESET)
    if hasattr(errno, 'WSAwhatever'):
       swallowed_connection_abort_ernos += (errno.WSAwhatever,)
    def ...:
        if ex.args[0] in self.swallowed_connection_abort_errnos:
             # swallow

I like that approach for a few reasons. One is that it gives us a place to use a doc-comment so we can document what we're doing and why. Another is that we could actually leave out WSAwhetever (if it truly is of a different kind than the other caught exceptions) and allow users to subclass or set an instance variable if they did need to catch it.

I'm happy to do the first part for sure (extract to a ivar and document).


This comment has been minimized.

jan11011977 commented Jul 21, 2017

Great! Thank you for your comments

Your suggestion of extracting the list of exceptions into a variable makes complete sense. I didn't realise that WSA* was a Windows-only exception although it seems obvious now that you mention it.

The Windows "connection was aborted by the software in your host machine" error is rather badly worded. It sounds like something has gone wrong with the local machine, but it actually means that the remote client closed the connection while our server was writing to it.

Some further explanation is here:

jamadden added a commit that referenced this pull request Jul 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment