[issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in HTTPConnection and the connection hangs

[Senthil Kumaran]

Senthil Kumaran  added the comment:

The _GLOBAL_DEFAULT_TIMEOUT usage is an established pattern with socket module. 
https://github.com/python/cpython/blob/main/Lib/socket.py#L805

This is not a bug and we don't have a good reproducible step mentioned in the 
report.

--
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://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

[Serhiy Storchaka]

Changes by Serhiy Storchaka storch...@gmail.com:


--
stage:  - test needed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12441
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://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

[Senthil Kumaran]

Senthil Kumaran sent...@uthcode.com added the comment:

Would you like to give an example snippet (server+client) which can help 
reproduce this behavior?

--
assignee:  - orsenthil
nosy: +orsenthil

___
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]

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]

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