[issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnection and the connection hangs
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
[issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnection and the connection hangs
Juanjo Alvarez juan...@gmail.com added the comment: PS: This only happens to my on Windows XP, works perfectly under Linux. -- ___ 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
Re: If Scheme is so good why MIT drops it?
On Jul 21, 6:57 am, Frank Buss f...@frank-buss.de wrote: Scott Burson wrote: Have you looked atECL? http://ecls.sourceforge.net/ I've used it only a little, so I can't vouch for its stability, but it fits the threading and license requirements (well, some corporate lawyers have trouble with the LGPL, but I think it's usable). I didn't tried it myself, but looks like it is not very stable: http://www.mail-archive.com/application-buil...@lispniks.com/msg01069... ECL suffers from fast development problems if this is what you mean. People are advised to stay with certain releases and we announce when some ports are broken due to progress along certain lines. For instance, if I find that the generational garbage collector is needed for Linux, FreeBSD, OpenBSD and OS X, and it works, I do not mind dropping temporarily the mingw port until the garbage collector library catches up. People who wanted to stay with mingw produced a branch (see Samium's posts) with the old garbage collector. Now this is not so dramatic. ECL now has a release cycle of ONE MONTH. If you find that this month's release does not work on your platform (and this is normally explicit in the announcement), then do not upgrade and wait one or two months until the problem is solved. OTOH, people only seem to notice problems when their petty platform is temporarily broken, but nobody seems to notice the overall stability and portability of the platform. See the list http://ecls.sourceforge.net/logs.html which will soon expand including Solaris and regular builds on Windows using the free Microsoft compiler. And once the ARM computer I have been gifted by a happy arrives, then Debian-ARM as well. Juanjo -- http://mail.python.org/mailman/listinfo/python-list
