Opened 10 years ago

Closed 10 years ago

#21773 closed Bug (fixed)

development server sometimes takes a long time to restart after source has been changed

Reported by: clime Owned by: mardini
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There are cases when development server takes a long time to restart after sources have been changed. It happens when an exception has been raised. I fix the exception and refresh the page but it keeps throwing the same error. I usually kill the server with ctrl-c to restart it manually. But then comes another problem when I try to start it, that is: "Error: That port is already in use." Django server does not release the port when being killed. Would it be possible to release it so I can start it immediately?

Change History (12)

comment:1 by clime, 10 years ago

One additional note, after ctrl-c, some thread of the server probably keeps running for some time because later I get a message about keyboard interrupt in the console. So that is probably the reason the port is not immediately available in such situations.

Last edited 10 years ago by clime (previous) (diff)

comment:2 by Marc Tamlyn, 10 years ago

Triage Stage: UnreviewedAccepted

I do occasionally see this behaviour. I have no idea what causes it. The thread continuing to run in the background is very annoying and normally I have to resort to kill

comment:3 by Aymeric Augustin, 10 years ago

Yes, I've seen that too. Last time I hit this problem, I had an infinite loop in a view.

comment:4 by Claude Paroz, 10 years ago

It would be useful to know on which platform(s) and which exact Django version that behavior arises, as the reload method might be different.

in reply to:  4 comment:5 by clime, 10 years ago

Replying to claudep:

It would be useful to know on which platform(s) and which exact Django version that behavior arises, as the reload method might be different.

The first version of Django I have used was 1.4 and I think I have been hitting this issue since beginning. I am totally sure that it is in 1.5 and 1.6.

The platform is linux/fedora. By the way I have just encountered this issue again. This exception was raised:

Environment:


Request Method: GET
Request URL: http://127.0.0.1:8008/messagethreads/

Django Version: 1.6.1
Python Version: 2.7.3
Installed Applications:
('django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'south',
 'grappelli',
 'django.contrib.admin',
 'django.contrib.admindocs',
 'endless_pagination',
 'debug_toolbar',
 'djangoratings',
 'imagekit',
 'watson',
 'web')
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'middleware.UserMemberMiddleware',
 'middleware.ProfilerMiddleware',
 'middleware.VaryOnAcceptMiddleware',
 'debug_toolbar.middleware.DebugToolbarMiddleware',
 'watson.middleware.SearchContextMiddleware')


Traceback:
File "/srv/www/envs/cb/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  107.                     response = middleware_method(request, callback, callback_args, callback_kwargs)
File "/srv/www/envs/cb/lib/python2.7/site-packages/debug_toolbar/middleware.py" in process_view
  73.             response = panel.process_view(request, view_func, view_args, view_kwargs)
File "/srv/www/envs/cb/lib/python2.7/site-packages/debug_toolbar/panels/profiling.py" in process_view
  133.         return self.profiler.runcall(view_func, *args, **view_kwargs)
File "/usr/lib64/python2.7/cProfile.py" in runcall
  149.             return func(*args, **kw)
File "/srv/www/envs/cb/lib/python2.7/site-packages/django/contrib/auth/decorators.py" in _wrapped_view
  22.                 return view_func(request, *args, **kwargs)
File "/srv/www/cb/web/views.py" in messagethread_list
  1176.         'model_tag': MessageThread.tag,

Exception Type: NameError at /messagethreads/
Exception Value: global name 'model_tag' is not defined

I fixed it and then tried to refresh the page repeatedly. Nevertheless, I was still getting the same exeption. In the end, I lost patience and decided to restart the server (the usual scenario). After killing it by ctrl-c, I tried to restart it:

^C(cb)clime@den /srv/www/cb ./manage.py runserver 127.0.0.1:8008
Validating models...

0 errors found
January 27, 2014 - 18:49:35
Django version 1.6.1, using settings 'cb.settings'
Starting development server at http://127.0.0.1:8008/
Quit the server with CONTROL-C.
Error: That port is already in use.
(cb)clime@den /srv/www/cb $ Exception KeyboardInterrupt in <module 'threading' from '/usr/lib64/python2.7/threading.pyc'> ignored

The KeyboardInterrupt exception appeared around 10 secs later. Then I could finally start the server again.

comment:6 by Tim Graham, 10 years ago

Component: UncategorizedCore (Management commands)

comment:7 by mardini, 10 years ago

It's probably not a bug in Django, it might be caused by ThreadingMixIn of Python's SocketServer module, which Django relies on. I didn't investigate it thoroughly though, so I'm not sure.

comment:8 by mardini, 10 years ago

Owner: changed from nobody to mardini
Status: newassigned

comment:9 by mardini, 10 years ago

Version: 1.6master

comment:11 by mardini, 10 years ago

Has patch: set

comment:12 by Tim Graham <timograham@…>, 10 years ago

Resolution: fixed
Status: assignedclosed

In 4f72e5f03ae803fd9faa1445245c1050ca004526:

Fixed #21773 -- made daemon threads default in the development server.

Thanks clime for the report.

Note: See TracTickets for help on using tickets.
Back to Top