id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
27316	Multiple LiveServerTestCase subclasses cannot reuse the same port	Jeremy Bowman	nobody	"The fix for #26011 (""allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows""), released with Django 1.10, seems to have had the unintended side effect of preventing a port from being reused for multiple subclasses of LiveServerTestCase in the same test suite.  I maintain a couple of libraries (sbo-selenium and django-nose-qunit) which facilitate Selenium testing of Django applications, and while updating them to work with 1.10 I noticed that both of them now fail with `OSError: [Errno 48] Address already in use` **after** the first test succeeds.  `DJANGO_LIVE_TEST_SERVER_ADDRESS` had been configured to use only a single port, and after updating it to use a range and inserting some debugging code, I noticed that subsequent test classes were needing to increment to ever higher port numbers in the range.  (I'm seeing this behavior at least on Mac OS X El Capitan, haven't yet tested more widely.)

The underlying problem seems to be described well at https://brokenbad.com/address-reuse-in-pythons-socketserver/ :

    Checking with netstat and ps, I found that although the process itself is no longer running, the socket is still listening on the port with status “TIME_WAIT”. Basically the OS waits for a while to make sure this connection has no remaining packets on the way.

I don't think we want to just revert the change that caused this, because it's true that we should not blindly ignore port conflicts with other processes.  Maybe it can be changed to set `allow_reuse_address=False` only for the first `LiveServerThread` in the process (to avoid stomping on any already-running processes), then flip a variable which would set it to `True` for all subsequent instances so each test class can reuse the same port?

As a workaround (and the reason I suspect this hadn't already been noticed), you can just assign a large range of ports in `DJANGO_LIVE_TEST_SERVER_ADDRESS` and let the tests cycle through them.  But this doesn't necessarily work in a large test suite with many subclasses of `LiveServerTestCase`, and there are cases where it's very useful for integration with other scripts to know deterministically which port will be used to run the server."	Bug	closed	Testing framework	1.10	Normal	fixed		Marten Kenbeek	Accepted	0	0	0	0	0	0