Enable longer wait in StoppableWSGIServer.shutdown / hardcoded parameter

[James Pic]

Hi all,

I found that there was a hard coded 2 seconds limit in
StoppableWSGIServer.shutdown:
https://github.com/django/django/blob/1.6/django/test/testcases.py#L999

This causes problems on slow boxes ie. travis:
https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/15177543

Can we enable configurable wait time in shutdown() ?

The we could use it like:

class WidgetTestCase(LiveServerTestCase)
shutdown_wait_time = 30 if os.environ.get('TRAVIS', False) else 2

What do you think ?

Thanks !

--
http://yourlabs.org
Customer is king - Le client est roi - El cliente es rey.

[Russell Keith-Magee]

On Tue, Dec 10, 2013 at 12:52 AM, James Pic <jame...@gmail.com> wrote:

Hi all,

I found that there was a hard coded 2 seconds limit in
StoppableWSGIServer.shutdown:
https://github.com/django/django/blob/1.6/django/test/testcases.py#L999

This causes problems on slow boxes ie. travis:
https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/15177543

Can we enable configurable wait time in shutdown() ?

The we could use it like:

    class WidgetTestCase(LiveServerTestCase)
        shutdown_wait_time = 30 if os.environ.get('TRAVIS', False) else 2

What do you think ?

Making this wait time configurable is certainly an option - however, is there any reason that we shouldn't just increase the timeout value? 

The 2 second value is a timeout limit -- it's a maximum value for waiting, not a minimum. It's needed because a second thread needs to shut down, and we need to wait until everything has stopped. If there's a common platform where 2 seconds isn't enough delay (and Travis would count IMHO), then why no just increase to something much bigger? In the "fast" case on good hardware, nothing will change; the "slow" case on Travis et al will allow for a graceful shutdown; and the genuine "its broken" case won't cause a lockup -- it will just take a lot longer to die. Yes, this will be annoying in the case of a problem, but not as annoying as false positives in a test case. Hardware is only going to get faster with time, so a limit that is big enough now is likely to stay that way.

Yours,

Russ Magee %-)

[Shai Berger]

Hi,

On Monday 09 December 2013 17:52:20 James Pic wrote:
> Hi all,
>
> I found that there was a hard coded 2 seconds limit in
> StoppableWSGIServer.shutdown:
> https://github.com/django/django/blob/1.6/django/test/testcases.py#L999
>
> This causes problems on slow boxes ie. travis:
> https://travis-ci.org/yourlabs/django-autocomplete-light/jobs/15177543
>
> Can we enable configurable wait time in shutdown() ?
>

This would be a new feature, and I think it is a little late for one of those
for 1.6. In 1.7, the whole StoppableWSGIServer class is gone -- with Python
2.7 and above, the stdlib's WSGIServer provides the needed functionality. You
might want to investigate how (if) timeouts are set for Python>=2.7's
WSGIServer -- at a glance, I didn't see any such thing in the Django code.

HTH,
Shai.

[James Pic]

Russ I think it would work if the timeout was just increased.

On Tue, Dec 10, 2013 at 12:36 AM, Shai Berger <sh...@platonix.com> wrote:
>
> This would be a new feature, and I think it is a little late for one of those
> for 1.6. In 1.7, the whole StoppableWSGIServer class is gone -- with Python
> 2.7 and above, the stdlib's WSGIServer provides the needed functionality. You
> might want to investigate how (if) timeouts are set for Python>=2.7's
> WSGIServer -- at a glance, I didn't see any such thing in the Django code.

True, I added django 1.7 to my test matrix and have experienced no
such problem. As for Django < 1.7 well .... the monkey patch is not
glorious: https://github.com/yourlabs/django-autocomplete-light/blob/v2/autocomplete_light/tests/widget.py#L14