Charles-Francois Natali neolo...@free.fr added the comment:
Skimming through the code, the only place where we can reasonably block is
inside HTTPConnection._send_output(), when the data is actually sent to the
socket.
What probably happens is the following:
- connect() call succeeded, we have an established TCP connection
- before request() is called - or in the middle of the sending - the host at
the other host goes down in brutal way, so that we don't receive a FIN/RST: the
TCP stack has no clue that the remote host went down
- we keep sending data through the socket, until the socket write buffer fills
up, and then, since httplib uses blocking sockets by default, we block on the
send() call
Now, depending on the TCP stack setting, after a given number of retries the
stack will decide the other host went down, and return an error. But this can
take a long time (under Linux, it's set by net.ipv4.tcp_retries2 sysctl by
default to 30 minutes).
The only thing that surprises me here is that when the host is back online, we
should get a RST, but it depends on the OS, the timeouts, maybe there's a
statefull firewall, etc.
So I'd say it's not a httplib issue here, it's just a standard behaviour of a
TCP connection when an host goes down.
Note that the solution is simply to use non-blocking socket, and it's already
implemented. Heck, it's even documented actually:
class httplib.HTTPConnection(host[, port[, strict[, timeout[,
source_address)
If the optional timeout parameter is given, blocking operations (like
connection attempts) will timeout after that many seconds (if it is not given,
the global default timeout setting is used).
So for me it's not an issue, but given the lack of infos, maybe I got it
completely wrong ;-)
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1531775
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
