[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Irit Katriel added the comment: There are still several tests that use find_unused_port: test_asyncio/test_events.py test_asyncio/test_proactor_events.py test_asyncio/test_sendfile.py test_asyncio/test_unix_events.py test_ftplib.py test_httplib.py test_largefile.py test_socket.py test_smtplib.

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Mark Lawrence added the comment: find_unused_port is only defined in test.support. It is tested in test.test_support. This solution might not be ideal but if it ain't broke, don't fix it? -- ___ Python tracker ___

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Vinay Sajip : -- nosy: -vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Paul Moore : -- nosy: -pmoore ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: TBH, I don't think I ever took this any further. As noted, the earlier patches fixed the failures I was hitting. It looks like Python 3.4 now has *two* definitions of find_unused_port, in test.test_support and in test.support. And test_asyncio and test_ftplib also

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Brian Curtin : -- nosy: -brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Mark Lawrence added the comment: msg104677, msg104822 and msg104845 refer to various commits but msg104955 suggests that a follow up is needed so where do we stand with this issue? -- nosy: +BreamoreBoy ___ Python tracker

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: Thanks for the suggestions, I'll see if I can implement something based on them. -- ___ Python tracker ___ _

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Jean-Paul Calderone added the comment: > One of the tests in test_socket is checking that an attempt to connect to a > port with no server running gives socket.error. For that, we need a port > that's guaranteed to have no server present. A good way to do this is to create a socket, bind it t

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: One of the tests in test_socket is checking that an attempt to connect to a port with no server running gives socket.error. For that, we need a port that's guaranteed to have no server present. I think that one of the tests in test_httplib checks the source_addre

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Jean-Paul Calderone added the comment: > You mean that socket.create_connection(), httplib (issue 3972) and ftplib > (issue 8594) should have used a different API to implement their > "source_address" option? I'm not sure what you mean. The problem here is that you cannot reliably bind a sp

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Antoine Pitrou : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/op

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: Roundup ate my code. I meant: >>> s = socket.create_connection(("python.org", 80), >>> source_address=("192.168.0.2", 0)) >>> s.getsockname() ('192.168.0.2', 40496) -- ___ Python tracker

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: > You mean that socket.create_connection(), httplib (issue 3972) and > ftplib (issue 8594) should have used a different API to implement > their "source_address" option? source_address=("192.168.0.2", 0)) >>> s.getsockname() ('192.168.0.2', 40

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Giampaolo Rodola' added the comment: > Any time you have any API that you want to test that requires a > pre-allocated port number, you're going to have intermittent failures. > Such APIs are broken and should be fixed where possible and avoided > otherwise. You mean that socket.create_conn

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Giampaolo Rodola' : -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Giampaolo Rodola' added the comment: > Any time you have any API that you want to test that requires a > pre-allocated port number, you're going to have intermittent failures. > Such APIs are broken and should be fixed where possible and avoided > otherwise. You mean that socket.create_conn

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Vinay Sajip added the comment: I've applied the logging patch and checked into trunk (r80712). -- ___ Python tracker ___ ___ Python-bu

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Jean-Paul Calderone added the comment: > I'm not sure if I agree that find_unused_port() should be removed though; it > does serve a purpose in very rare corner cases. It can serve a purpose in any number of cases. My point is that it's *always* unreliable, though. Any time you have any API

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Trent Nelson added the comment: I introduced test_support.find_unused_port in r62234, as part of a general refactoring of client/server network-oriented tests. The only reason I introduced this method at the time was because the SSL tests used to launch openssl in server mode, which required

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: > See, for example, the test for "source_address" parameter of > socket.create_connection() function. Instead of testing the port, you could test the host. For example by using two different loopback addresses (127.0.0.1 and 127.0.0.2?). Would it work on every

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Giampaolo Rodola' added the comment: > find_unused_port is the wrong approach altogether. Uses of it should > be replaced by bind_port and then find_unused_port should be removed I agree find_unused_port() is the wrong approach in general, but there are certain cases where this is needed. S

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: Might work - but the only ones that were actually failing for me were test_multiprocessing and test_smtplib. So I'm not quite sure where/when the error would be raised on the remaining 2 (socket & httplib). But I'll keep it in mind. To be honest, the remaining t

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

R. David Murray added the comment: Could you special case the test_socket test by checking for the error that Windows sometimes throws and retrying (in a loop for say a second)? Not ideal, but probably better than adding a sleep or throwing away the test :) -- nosy: +r.david.murray

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: Vinay, are you ok with the proposed patch? -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-b

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: Here's a patch for test_logging. It needed a minor tweak to logging.config - but I can't see anywhere that this affects the documentation, so I didn't do a doc patch. I hope that's OK. I'll have a look at test_socket but that looks a bit too deep for me. And tes

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Antoine Pitrou added the comment: > OK. I've attached a patch which removes the use of get_unused_port for > test_smtplib and test_multiprocessing. Great, thank you. It was committed in r80669 (trunk), r80670 (2.6), r80671 (py3k), r80672 (3.1). Note that there are still a couple of tests usin

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Paul Moore added the comment: OK. I've attached a patch which removes the use of get_unused_port for test_smtplib and test_multiprocessing. It doesn't use bind_port as both cases test classes that create their own port internally, rather I've used port 0 and then introspected the actual port

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Jean-Paul Calderone added the comment: find_unused_port is the wrong approach altogether. Uses of it should be replaced by bind_port and then find_unused_port should be removed. -- ___ Python tracker

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Antoine Pitrou : -- nosy: +brian.curtin, exarkun, tim.golden type: -> behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker ___ ___

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

Changes by Paul Moore : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue8576] test_support.find_unused_port can cause socket conflicts on Windows

New submission from Paul Moore : test_support.find_unused_port attempts to find an unused port to use. The approach is fragile (as noted in the docstring) in certain cases. In particular, it appears that Windows takes a short time to free the socket after it is closed, meaning that when the ca