This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author juanjux
Recipients juanjux
Date 2011-06-29.11:18:38
SpamBayes Score 5.418957e-08
Marked as misclassified No
Message-id <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-06-29 11:18:39juanjuxsetrecipients: + juanjux
2011-06-29 11:18:39juanjuxsetmessageid: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
2011-06-29 11:18:39juanjuxlinkissue12441 messages
2011-06-29 11:18:38juanjuxcreate