Roundup Tracker - Issues

Message6156

Author joseph_myers
Recipients ber, jerrykan, joseph_myers, rouilj
Date 2018-08-01.10:13:50
Message-id <1533118430.94.0.56676864532.issue2550750@psf.upfronthosting.co.za>
In-reply-to
If you have such an option to control timeout handling, it raises more
questions.  The current code has:

    # list of network error codes that shouldn't be reported to tracker
admin
    # (error descriptions from FreeBSD intro(2))
    IGNORE_NET_ERRORS = (
        # A write on a pipe, socket or FIFO for which there is
        # no process to read the data.
        errno.EPIPE,
        # A connection was forcibly closed by a peer.
        # This normally results from a loss of the connection
        # on the remote socket due to a timeout or a reboot.
        errno.ECONNRESET,
        # Software caused connection abort.  A connection abort
        # was caused internal to your host machine.
        errno.ECONNABORTED,
        # A connect or send request failed because the connected party
        # did not properly respond after a period of time.
        errno.ETIMEDOUT,
    )

[...]

        try:
            call(*args, **kwargs)
        except socket.error as err:
            err_errno = getattr (err, 'errno', None)
            if err_errno is None:
                try:
                    err_errno = err[0]
                except TypeError:
                    pass
            if err_errno not in self.IGNORE_NET_ERRORS:
                raise
        except IOError:
            # Apache's mod_python will raise IOError -- without an
            # accompanying errno -- when a write to the client fails.
            # A common case is that the client has closed the
            # connection.  There's no way to be certain that this is
            # the situation that has occurred here, but that is the
            # most likely case.
            pass

So the existing expectation is that all those errors (including a
timeout if it somehow ends up as socket.error with ETIMEDOUT) are
ignored.  Does such an option also result in ETIMEDOUT being handled
differently?  Does it affect the other forms of socket errors or should
those have another option to affect them?  In the mod_python case, is it
possible to distinguish timeouts anyway or will they just go through the
generic IOError case?
History
Date User Action Args
2018-08-01 10:13:50joseph_myerssetmessageid: <1533118430.94.0.56676864532.issue2550750@psf.upfronthosting.co.za>
2018-08-01 10:13:50joseph_myerssetrecipients: + joseph_myers, ber, rouilj, jerrykan
2018-08-01 10:13:50joseph_myerslinkissue2550750 messages
2018-08-01 10:13:50joseph_myerscreate