Author neologix
Recipients bgilbert, neologix, pitrou
Date 2011-10-24.17:16:03
SpamBayes Score 2.14207e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
>  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 funny, I noticed this a couple days ago, and it also puzzled me...

> 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.

That's also what I think.
But that's strange, since:
- this holds for every client/server communication (e.g. why not do
that for smtplib, telnetlib, etc. ?)
- it's against the classical connect() semantics
- some code may prefer failing immediately (instead of "hammering" the
remote host) if the remote server is down, or the address is
incorrect: it can still handle the ECONNREFUSED if it wants to retry,
with a custom retry timeout
I removed the retry code and run test_multiprocessing and
test_concurrent_futures in loop, and didn't see any failure (on
Linux), so I'd say we could probably remove that.
OTOH, I would feel bad if this broke someone's code (even though code
relying on the automatic retries is probably broken).
So I'm +1 on removing the retry logic altogether, unless of course
someone comes up with a good reason to keep it (I digged a little
through the logs to see when this was introduced, but apparently it
was there in the original import).
If we don't remove it, I agree we should at least reduce the timeout
and increase the period (an exponential backoff may be a bit
Date User Action Args
2011-10-24 17:16:05neologixsetrecipients: + neologix, pitrou, bgilbert
2011-10-24 17:16:04neologixlinkissue13215 messages
2011-10-24 17:16:03neologixcreate