Celery: исправление документации для django 1.7 «Реестр приложений еще не готов»

Это исправлено в ветке 3.1 и станет частью 3.1.13.

Глядя на это, это уже должно было быть исправлено в 3.1.12.

У меня точно тоже работает при запуске воркера? Когда именно у вас возникли проблемы?

Модуль proj/celery.py определенно не должен вызывать django.setup() , он обрабатывается «исправлениями django» при запуске рабочего.

Я думаю, что это была проблема с моим virtualenv. Я удалил и переустановил сельдерей и теперь не вижу проблемы после вашего последнего комментария.

Похоже, это НЕ исправлено в 3.1.13.

Что вы имеете в виду под внешностью?

Ну я сейчас борюсь с этой проблемой. Я не могу получить доступ ни к одной модели в моем файле tasks.py из-за AppRegistryNotReady . Я использую 3.1.13 от PyPI.

Один вопрос, поскольку я занимаюсь отладкой... следует ли вызывать celery.fixups.django.DjangoWorkerFixup.validate_models один раз при запуске демона celery или один раз для каждого рабочего?

Похоже, он вызывается один раз, и к этому времени стек выглядит так:

И да, у меня Windows 8 + Python 2.7 32-бит.

Что касается 3.1.13, пожалуйста, повторно откройте эту ошибку.

Даже если процедура django.setup() вызывается в django.py, я получаю эту трассировку.

[2014-07-18 16:15:35,117: ERROR/Worker-1] bpp.tasks.zaktualizuj_opis[8e93003c-fca4-4970-8be3-32eeede5fbb1]: Problem z pobraniem obiektu
Traceback (most recent call last):
  File "C:/Users/dotz/Desktop/django-bpp\bpp\tasks.py", line 79, in zaktualizuj_opis
    obj = klasa.objects.get(pk=pk)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\manager.py", line 92, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\query.py", line 345, in get
    clone = self.filter(*args, **kwargs)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\query.py", line 689, in filter
    return self._filter_or_exclude(False, *args, **kwargs)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\query.py", line 707, in _filter_or_exclude
    clone.query.add_q(Q(*args, **kwargs))
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\sql\query.py", line 1287, in add_q
    clause, require_inner = self._add_q(where_part, self.used_aliases)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\sql\query.py", line 1314, in _add_q
    current_negated=current_negated, connector=connector)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\sql\query.py", line 1138, in build_filter
    lookups, parts, reffed_aggregate = self.solve_lookup_type(arg)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\sql\query.py", line 1076, in solve_lookup_type
    _, field, _, lookup_parts = self.names_to_path(lookup_splitted, self.get_meta())
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\sql\query.py", line 1339, in names_to_path
    field, model, direct, m2m = opts.get_field_by_name(name)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\options.py", line 416, in get_field_by_name
    cache = self.init_name_map()
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\options.py", line 445, in init_name_map
    for f, model in self.get_all_related_m2m_objects_with_model():
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\options.py", line 561, in get_all_related_m2m_objects_with_model
    cache = self._fill_related_many_to_many_cache()
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\db\models\options.py", line 575, in _fill_related_many_to_many_cache
    for klass in self.apps.get_models():
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\utils\lru_cache.py", line 101, in wrapper
    result = user_function(*args, **kwds)
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\apps\registry.py", line 156, in get_models
    self.check_ready()
  File "c:\users\dotz\desktop\django-bpp\venv\lib\site-packages\django\apps\registry.py", line 119, in check_ready
    raise AppRegistryNotReady()
AppRegistryNotReady

Однако это не та же проблема, пользователи ни при каких обстоятельствах не должны добавлять django.setup() в proj/celery.py.

В Windows нет форка, поэтому он эмулирует его, запуская совершенно новый процесс (например, exec в posix). Вполне возможно, что исправления должны быть применены и к дочерним процессам.

В каком месте лучше всего вызывать django.setup() в рабочем коде?

Я безуспешно добавил django.setup() celery.apps.worker.Worker.on_after_init.

сигнал worker_process_init возможно

То же самое. Моя установка Django 1.7c2, сельдерей 3.1.13.

send_messages.delay(self) # <- self is a model_onstance

<strong i="6">@shared_task</strong>
def send_messages(jmodel_instance):

    if job_model_instance.field_type == 'SM':
        do_stuff()

Ошибка:

raise AppRegistryNotReady("Models aren't loaded yet.")

У меня была такая же проблема с Django 1.7rc2 и celery 3.1.13 в практически пустом тестовом проекте. У меня даже нет и не нужны модели, поэтому я могу подтвердить, что это в моем tasks.py решило проблему для меня:

from celery.signals import worker_process_init
@worker_process_init.connect
def configure_workers(*args, **kwargs):
    import django
    django.setup()

У меня не работает к сожалению.

Вы все используете Windows? Разве вы не получаете трассировку, когда это происходит?

Я использую Mac. Вот полный след.

    DecodeError: (AppRegistryNotReady("Models aren't loaded yet.",), <function model_unpickle at 0x10d44f668>, (('jobs', 'Job'), [], <function simple_class_factory at 0x10d44f5f0>))
    [2014-08-06 19:59:00,636: CRITICAL/MainProcess] Can't decode message body: DecodeError(AppRegistryNotReady(AppRegistryNotReady("Models aren't loaded yet.",), <function model_unpickle at 0x10d44f668>, (('jobs', 'Job'), [], <function simple_class_factory at 0x10d44f5f0>)),) [type:u'application/x-python-serialize' encoding:u'binary' headers:{}]

    body: '\x80\x02}q\x01(U\x07expiresq\x02NU\x03utcq\x03\x88U\x04argsq\x04cdjango.db.models.base\nmodel_unpickle\nq\x05U\x04jobsq\x06U\x03Jobq\x07\x86]cdjango.db.models.base\nsimple_class_factory\nq\x08\x87Rq\t}q\n(U\x0f_schedule_cacheNU\x0btemplate_idK\x01U\x11_created_by_cachecdjango.contrib.auth.models\nUser\nq\x0b)\x81q\x0c}q\r(U\x08usernameq\x0eX\x06\x00\x00\x00jannikU\nfirst_nameq\x0fX\x00\x00\x00\x00U\tlast_nameq\x10X\x00\x00\x00\x00U\tis_activeq\x11\x88U\x06_stateq\x12cdjango.db.models.base\nModelState\nq\x13)\x81q\x14}q\x15(U\x06addingq\x16\x89U\x02dbq\x17U\x07defaultq\x18ubU\x05emailq\x19X\x17\x00\x00\[email protected]\x0cis_superuserq\x1a\x88U\x08is_staffq\x1b\x88U\nlast_loginq\x1ccdatetime\ndatetime\nq\x1dU\n\x07\xde\x08\x05\x1255\x07x\x0ccpytz\n_UTC\nq\x1e)Rq\x1f\x86Rq... (1211b)
    Traceback (most recent call last):
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/messaging.py", line 586, in _receive_callback
        decoded = None if on_m else message.decode()
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/message.py", line 142, in decode
        self.content_encoding, accept=self.accept)
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/serialization.py", line 184, in loads
        return decode(data)
      File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/contextlib.py", line 35, in __exit__
        self.gen.throw(type, value, traceback)
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/serialization.py", line 59, in _reraise_errors
        reraise(wrapper, wrapper(exc), sys.exc_info()[2])
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/serialization.py", line 55, in _reraise_errors
        yield
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/serialization.py", line 184, in loads
        return decode(data)
      File "MYPROJECT/venv/lib/python2.7/site-packages/kombu/serialization.py", line 64, in pickle_loads
        return load(BytesIO(s))
      File "MYPROJECT/venv/lib/python2.7/site-packages/django/db/models/base.py", line 1471, in model_unpickle
        model = apps.get_model(*model_id)
      File "MYPROJECT/venv/lib/python2.7/site-packages/django/apps/registry.py", line 199, in get_model
        self.check_models_ready()
      File "MYPROJECT/venv/lib/python2.7/site-packages/django/apps/registry.py", line 131, in check_models_ready
        raise AppRegistryNotReady("Models aren't loaded yet.")
    DecodeError: (AppRegistryNotReady("Models aren't loaded yet.",), <function model_unpickle at 0x10d44f668>, (('jobs', 'Job'), [], <function simple_class_factory at 0x10d44f5f0>))

Коммит 0882ab5b7d7cfcd4cb43b7240352215425eb471d должен исправить это в Windows.

@ j7nn7k Вы на 100% уверены, что не используете djcelery.setup_loader() ?

Я _am_ использую djcelery.setup_loader() , почему бы и нет?

Это есть в инструкциях , и если у меня его нет, то BROKER_BACKEND = 'django' в моем settings.py как бы игнорируется и сельдерей жалуется на невозможность подключиться к amqp://guest:**@127.0.0.1:5672/ (правильно, т.к. у меня этого нет) вместо использования бэкэнда Django.

Я не использую djcelery.setup_loader()

Догадаться.
Я сделал две ошибки.

1.) Я не запускал сельдерей с параметром приложения (-A).

неправильный:
celery worker

правильно:
celery worker -A proj # <- executed from manage.py dir

2.)
Не указаны правильные настройки django в celery.py. Это мой конфиг для разработки.

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings_dev')

Извините, ребята, и спасибо за вашу помощь!

Эта документация устарела, и использование setup_loader отключит интеграцию ядра сельдерея. Он просто предполагает, что вы используете старую интеграцию django-celery.

Канонические документы находятся здесь: http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html .
Не смешивайте и не сочетайте новые и старые руководства, поэтому, если вы настаиваете на использовании старой интеграции django-celery,
вам, вероятно, также не следует иметь celery.py , особенно тот, который устанавливает среду DJANGO_SETTINGS_MODULE .

Если вы используете setup_loader , то вы используете manage.py celery и добавляете djcelery в установленные приложения,
как в старые времена.

@ j7nn7k Приятно знать, что это работает. -A необходимо использовать, чтобы он нашел экземпляр вашего приложения Celery, и когда он импортирует модуль celery.py , он также будет иметь правильный набор DJANGO_SETTINGS_MODULE .
( -A proj — это сокращение от -A proj.celery:app , что означает, что рабочий сделает from proj.celery import app )

У меня аналогичная ошибка, когда я пытаюсь использовать django.utils.translation.ugettext в своих моделях.py
Я на Linux, Django 1.7 rc2, Celery v3.1.13

Все в соответствии с http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html
След:

(env)limpbrains<strong i="10">@omg</strong>:~/dev/cc$ celery -A tst worker --loglevel=debug
Traceback (most recent call last):
  File "/home/limpbrains/dev/cc/env/bin/celery", line 11, in <module>
    sys.exit(main())
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/__main__.py", line 30, in main
    main()
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/celery.py", line 81, in main
    cmd.execute_from_commandline(argv)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/celery.py", line 769, in execute_from_commandline
    super(CeleryCommand, self).execute_from_commandline(argv)))
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/base.py", line 307, in execute_from_commandline
    return self.handle_argv(self.prog_name, argv[1:])
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/celery.py", line 761, in handle_argv
    return self.execute(command, argv)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/celery.py", line 693, in execute
    ).run_from_argv(self.prog_name, argv[1:], command=argv[0])
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/worker.py", line 179, in run_from_argv
    return self(*args, **options)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/base.py", line 270, in __call__
    ret = self.run(*args, **kwargs)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/bin/worker.py", line 212, in run
    state_db=self.node_format(state_db, hostname), **kwargs
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/worker/__init__.py", line 95, in __init__
    self.app.loader.init_worker()
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/loaders/base.py", line 128, in init_worker
    self.import_default_modules()
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/loaders/base.py", line 116, in import_default_modules
    signals.import_modules.send(sender=self.app)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/utils/dispatch/signal.py", line 166, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/amqp/utils.py", line 42, in __call__
    self.set_error_state(exc)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/amqp/utils.py", line 39, in __call__
    **dict(self.kwargs, **kwargs) if self.kwargs else kwargs
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/app/base.py", line 329, in _autodiscover_tasks
    self.loader.autodiscover_tasks(packages, related_name)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/loaders/base.py", line 251, in autodiscover_tasks
    related_name) if mod)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/loaders/base.py", line 272, in autodiscover_tasks
    return [find_related_module(pkg, related_name) for pkg in packages]
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/celery/loaders/base.py", line 291, in find_related_module
    return importlib.import_module('{0}.{1}'.format(package, related_name))
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/home/limpbrains/dev/cc/env/src/django-cc/cc/tasks.py", line 9, in <module>
    from cc.models import Wallet
  File "/home/limpbrains/dev/cc/env/src/django-cc/cc/models.py", line 18, in <module>
    class Wallet(models.Model):
  File "/home/limpbrains/dev/cc/env/src/django-cc/cc/models.py", line 19, in Wallet
    currency = models.CharField(_('Currency'), max_length=3, choices=currencies_coices())
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/django/utils/translation/__init__.py", line 83, in ugettext
    return _trans.ugettext(message)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 325, in ugettext
    return do_translate(message, 'ugettext')
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 306, in do_translate
    _default = translation(settings.LANGUAGE_CODE)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 209, in translation
    default_translation = _fetch(settings.LANGUAGE_CODE)
  File "/home/limpbrains/dev/cc/env/local/lib/python2.7/site-packages/django/utils/translation/trans_real.py", line 189, in _fetch
    "The translation infrastructure cannot be initialized before the "
django.core.exceptions.AppRegistryNotReady: The translation infrastructure cannot be initialized before the apps registry is ready. Check that you don't make non-lazy gettext calls at import time.

@ask Я использую setup_loader , у меня есть djcelery в установленных приложениях, у меня нет celery.py , и я использую manage.py celery для все команды управления. Насколько я могу судить, я полностью следую «старым инструкциям» и не смешиваю и не подбираю.

К вашему сведению: причина, по которой у меня была эта проблема только в небольшом тестовом проекте, а не в моем основном проекте, заключается в том, что там я использую CELERYD_POOL = 'celery.concurrency.threads:TaskPool' для разработки.

Привет. Это не работает для меня
> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"

джанго 1.7rc3
сельдерей 3.1.13

я пытаюсь бежать
celery worker -A <project_name>

и я получаю

django.core.exceptions.AppRegistryNotReady: модели еще не загружены.

Есть ли что-то еще, что я должен делать?

У меня тоже есть эта ошибка, такая же, как у @limpbrains

The translation infrastructure cannot be initialized before the apps registry is ready

Кто-нибудь нашел решение?

из django.core.wsgi импортировать get_wsgi_application
application = get_wsgi_application() может решить эту проблему! @webjunkie

я добавляю from django.contrib.auth.admin import User в models.py _ (я уверен, что проблема вызвана этой строкой)_
затем python manage.py syncdb
django1.7 поднял:

  File "/home/jijing/lab/django17/lib/python2.7/site-packages/django/db/models/options.py", line 577, in _fill_related_many_to_many_cache
    for klass in self.apps.get_models():
  File "/home/jijing/lab/django17/lib/python2.7/site-packages/django/utils/lru_cache.py", line 101, in wrapper
    result = user_function(*args, **kwds)
  File "/home/jijing/lab/django17/lib/python2.7/site-packages/django/apps/registry.py", line 168, in get_models
    self.check_models_ready()
  File "/home/jijing/lab/django17/lib/python2.7/site-packages/django/apps/registry.py", line 131, in check_models_ready
    raise AppRegistryNotReady("Models aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Models aren't loaded yet.

из django.core.wsgi импортировать get_wsgi_application
приложение = get_wsgi_application()
обновленный джанго 1.7
Это выше не исправило мою ошибку ниже для перевода

Инфраструктура перевода не может быть инициализирована до тех пор, пока не будет готов реестр приложений.
какие еще вещи я должен изменить.

У меня такая же проблема, я обновился до django 1.7 и теперь получаю исключение AppRegistryNotReady. Я использую старую установку django-celery.

Я использую демон celeryd для запуска рабочих. Обратите внимание, что если я запускаю их вручную, используя
python manage.py celery worker --loglevel=info
это работает. Но при использовании команды celery multi, которая используется celeryd, я получаю исключение AppRegistryNotReady.

Я также сталкиваюсь с той же проблемой.
поднять AppRegistryNotReady("Модели еще не загружены")

В документации по Celery есть много ссылок, которые показывают различные способы интеграции celery с DJANGO. Один говорит включить celery.py в основной проект. В другом есть djcelery. Все просто растворились в замешательстве.

Я задокументировал свою проблему по следующей ссылке. Кто исправлял, ответьте.

https://groups.google.com/forum/#!topic/django-users/c_LOQ_nUvmw

У меня такая же проблема ( AppRegistryNotReady: Models aren't loaded yet. ) в Windows 8.1 и Django 1.7 с использованием djcelery==3.1.16 .

Это сработало для меня:

$ (env) pip uninstall celery
$ (env) pip install celery

Кстати, я согласен с @findsarfaraz — документация по интеграции Celery с Django сбивает с толку.

@ask У меня такая же проблема. Я только что обновил Django с 1.6 до 1.7 (используя Heroku/Forman для локальной разработки). Версия сельдерея 3.1.17. У меня также установлен django-celery версии 3.1.16.

В моем файле wsgi.py используется правильный синтаксис приложения:

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

... и мой Procfile выглядит следующим образом:

web: newrelic-admin run-program gunicorn -c gunicorn.py.ini wsgi:application
scheduler: newrelic-admin run-program celery beat --loglevel=INFO --app=api.celery:app
worker: newrelic-admin run-program celery worker -Q celery -E --loglevel=INFO --maxtasksperchild=200 --app=api.celery:app
periodic: newrelic-admin run-program celery worker -Q periodic -E --loglevel=INFO --maxtasksperchild=200 --app=api.celery:app

Когда я удаляю строки scheduler , worker и periodic , foreman start выполняется правильно и работает без сучка и задоринки. Но когда я снова добавляю команды Celery, я получаю:

django.core.exceptions.AppRegistryNotReady: The translation infrastructure cannot be initialized before the apps registry is ready. Check that you don't make non-lazy gettext calls at import time.

Однако, когда я запускаю из своей командной строки:

foreman run python manage.py celery worker -Q celery -E --loglevel=INFO --maxtasksperchild=200 --app=api.celery:app

Он работает правильно. Любые мысли здесь? Кажется, это как-то связано с тем, как Celery загружает модуль переводов Django.

@limpbrains @sreedharbukya @ask Мне удалось исправить ошибку, изменив файл celery.py . Изначально было:

# ...
app = Celery('api')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')
# ...

Я просто переключил эти 2 строки, и проблема была решена, поэтому:

# ...
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'proj.settings')
app = Celery('api')
# ...

Надеюсь, это кому-нибудь поможет!

@mkuchen хахаха из всех, кого можно встретить в комментарии на github :)

Ну ты просто помог мне!

@adambratt скажи, чтоооо! Какое совпадение. IIRC, вы были тем, кто познакомил меня с сельдереем в первую очередь. Разговор о полном круге!

Эта проблема по-прежнему возникает в Linux 14.04, Django 1.7, Celery 3.1.18. Есть ли известное исправление/обходной путь/обновление для этого @ask? История изменений в документах подразумевает, что 3.1.14/15 исправляет это.

Добавление того, что сработало для меня, если это кому-то поможет:

Ни одно из вышеперечисленных решений, которые я читал в этой и других темах, не сработало для меня. Я запускаю Django 1.8, Celery 3.1.18, django-celery 3.1.6 и запускаю воркеры через manage.py celery .

Что, по-видимому, волшебным образом решило проблему "Models aren't loaded yet." для меня, так это отключение CELERYD_FORCE_EXECV , как настоятельно рекомендуется в примечаниях к выпуску celery 3.1.7: http://docs.celeryproject.org/en/latest/changelog .html#версия -3-1-17

(Хотя кажется, что эти две вещи не должны быть связаны).

Я не думаю, что это актуальная проблема, больше о некоторых распространенных ловушках при интеграции django/celery.