Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 34fcc0d5c3c5 by Charles-François Natali in branch 'default':
Issue #13215: multiprocessing.Connection: don't hammer the remote end with
http://hg.python.org/cpython/rev/34fcc0d5c3c5
--
nosy: +python-dev
Charles-François Natali neolo...@free.fr added the comment:
Benjamin, thanks for the report.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Charles-François Natali neolo...@free.fr added the comment:
Apparently you forgot to upload the patch...
Told you I couldn't think straight :-)
--
Added file: http://bugs.python.org/file23720/connection_retry.diff
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Ok for me. Nice to see that piece of ugliness removed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13215
___
Antoine Pitrou pit...@free.fr added the comment:
Apparently you forgot to upload the patch...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13215
___
Charles-François Natali neolo...@free.fr added the comment:
Here's a patch removing the automatic retry on ECONNREFUSED: I tested it on
Linux and other Unices, and it seems to work just fine without this hammering.
Note that there's a similar mechanism for Windows (ERROR_PIPE_BUSY), but it
Charles-François Natali neolo...@free.fr added the comment:
While a 20 second timeout may make sense for *unresponsive* servers,
ECONNREFUSED probably indicates that the server is not listening on this
port, so
hammering it with 1,999 more connection attempts isn't going to help.
That's
Antoine Pitrou pit...@free.fr added the comment:
I'm not sure, but I think that would be for the case where you are spawning the
server yourself and the child process takes time to start up.
--
nosy: +neologix, pitrou
___
Python tracker
New submission from Benjamin Gilbert bgilb...@backtick.net:
multiprocessing.managers.BaseManager.connect() takes 20 seconds to return on
failure, even if the server refuses the connection. This is because the
function that creates the connection,
multiprocessing.connection.SocketClient(),