CODEWITHSUNDEEP
djangoheroku
Tom Manterfield
Tom Manterfield

Reputation: 7073

Intermittent error --ImproperlyConfigured: The included urlconf doesn't have any patterns in it

First of all, I have seen many similar questions about this, though they all seem to be different problems based on a couple of factors.

I am getting a weird error in my Django project when deployed to Heroku. The error is weird because The urlconf and all included urlconfs have valid content. The error is intermittent, the same URL can (and usually will) result in a successful request. I don't have django debug toolbar installed (mentioned as a cause of this in other questions) and I don't have reverse() being used other than within methods on the view classes (not params etc.)

The trace is below, anything at all in terms of hints of where to look would be incredibly useful.

 Traceback (most recent call last):

      File "/app/.heroku/python/lib/python2.7/site-packages/django/core/handlers/base.py", line 90, in get_response
        response = middleware_method(request)

      File "/app/.heroku/python/lib/python2.7/site-packages/newrelic-2.16.0.12/newrelic/hooks/framework_django.py", line 215, in wrapper
        return wrapped(*args, **kwargs)

      File "/app/.heroku/python/lib/python2.7/site-packages/django/middleware/common.py", line 71, in process_request
        if (not urlresolvers.is_valid_path(request.path_info, urlconf) and

      File "/app/.heroku/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 573, in is_valid_path
        resolve(path, urlconf)

      File "/app/.heroku/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 453, in resolve
        return get_resolver(urlconf).resolve(path)

      File "/app/.heroku/python/lib/python2.7/site-packages/newrelic-2.16.0.12/newrelic/hooks/framework_django.py", line 518, in wrapper
        return wrapped(*args, **kwargs)

      File "/app/.heroku/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 318, in resolve
        for pattern in self.url_patterns:

      File "/app/.heroku/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 350, in url_patterns
        raise ImproperlyConfigured("The included urlconf %s doesn't have any patterns in it" % self.urlconf_name)

    ImproperlyConfigured: The included urlconf core.urls doesn't have any patterns in it

At the moment I am not even sure how to start debugging this, which is the biggest issue. The only way I have of duplicating right now is running a siege against the server, eventually when the traffic has been high for a while these failures become more common.

Upvotes: 3

Views: 357

Answers (2)

Subramanian
Subramanian

Reputation: 1

Django will load your urlconf when it receives the first request. Gunicorn will spawn new worker processes as per configuration/instruction. For e.g. after max_requests have been processed by a worker, or after manually deploying new code.

Now, if you are using the gevent worker, one of these workers might receive multiple concurrent requests. While your worker is working on the first request and loading the URLConf, it might decide to serve another request if there is some IO operation in the URLConf import (Remember, the first time this gets imported, all your views and any other recursive imports will also happen.).

However since your URLConf is not imported completely, the regex for the next request will not match and an exception will be raised.

You can consider reducing the time it takes to import the URLConf. The race condition, however, still exists as @Tom Dickin pointed out.

Upvotes: 0

Tom Manterfield
Tom Manterfield

Reputation: 7073

In the end I found an issue raised on Gunicorn's github which describes this race condition.

Adding a gunicorn conf like so:

def post_fork(server, worker):
    from django.core.urlresolvers import resolve
    resolve('/')

With the Procfile:

web: gunicorn core.wsgi:application -b "0.0.0.0:$PORT" -w 5 -k gevent --max-requests 250 --preload --settings=core.settings -c /app/core/gunicorn_conf.py

Seems to have completely removed this error.

That being said, the procfile changed from the django run_gunicorn management command at the same time, so either of those changes could have been the fix.

I have no desire to go back and break it again to see which it was, so if anyone tries them both and can tell for sure which it was, please leave an answer.

Upvotes: 1

Related Questions