allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows

[Marten Kenbeek]

Windows happily allows a process to steal another process's address when SO_REUSEADDR is set. This can cause requests to go to the wrong LiveServerThread, and cause random test failures, such as ​http://djangoci.com/job/pull-requests-windows/886/. I can't reproduce this issue on Linux.

The solution is quite simply to set allow_reuse_address to 0 on our WSGIServer implementation. The question is whether we want to do that only when running a LiveServerTestCase, or on the base WSGIServer class to prevent address stealing for manage.py runserver as well.

[Tim Graham]

Thanks for investigating that. Unfortunately, I can't advise on the proper solution.

[Marten Kenbeek]

PR: ​https://github.com/django/django/pull/5895

[Tim Graham <timograham@…>]

In c87540ce:

Fixed #26011 -- Prevented random LiveServerTestCase test failures on Windows.

Prevented LiveServerTestCase from stealing ports used by concurrent
processes on Windows.

[Tim Graham]

Saw this error on Jenkins with Python 2:

Traceback (most recent call last):
  File "/home/jenkins/workspace/django-master-trusty/database/sqlite3/label/trusty/python/python2.7/tests/servers/tests.py", line 191, in test_port_bind
    if e.ernrno == errno.EADDRINUSE:
AttributeError: 'error' object has no attribute 'ernrno'

[Marten Kenbeek]

New PR: ​https://github.com/django/django/pull/5918

[Tim Graham <timograham@…>]

In b551eda:

Refs #26011 -- Fixed AttributeError in test_port_bind test.

[Tim Graham]

Could ​these Jenkins failures be related?

[Marten Kenbeek]

I think this patch exposes an existing bug. The current code expects the error when a socket is in use to be an socket.error instance, but apparently it raises an OSError in some circumstances. According to the Py3 docs, an OSError should automatically be "upgraded" to the appropriate error type, but that doesn't seem to happen here. For our case it should be sufficient to catch an OSError as well (we still need to catch socket.error on Py2), and check the error code. I'm not sure why the OSError constructor does not return a socket.error, this might be a bug in Python. I'll investigate this later.