New submission from Juanjo Alvarez <juan...@gmail.com>: I was testing a jsonrpc server using a small Python client. I noticed that sometimes when the RPC returned some long test, the response object returned by URLOpener.open(), in my case an HTTPResponse, would hang about 70% of the time when calling read() on a RPC method returning more text than usual (a string of about 4000 bytes).
Investigating it I noticed that on HTTPConnection.connect, the self.timeout value was "object". I tried to hardcode some value on the method first line, changing the "self.timeout" for "5": self.sock = socket.create_connection((self.host,self.port),self.timeout, self.source_address) Then suddenly the call to the RPC works 100% of the time, and I don't mean that it timeouts, it just works and doesn't hangs. So the workaround that I'm using is to call socket.setdefaulttimeout in my client code. I saw that the default value in HTTPConnection for self.timeout is socket._GLOBAL_DEFAULT_TIMEOUT which is initialized as an "object()" and remains that way on my HTTPConnection.connect call. My guess is that when the RPC call is not very fast, the system checks the socket timeout and then it hangs if the value is an object, so the longer the text returned by the RPC, the higher the chance that the read() hangs. ---------- components: IO messages: 139406 nosy: juanjux priority: normal severity: normal status: open title: _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnection and the connection hangs type: behavior versions: Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12441> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
