Задача Celery, кажется, делает все, кроме записи в базу данных

Question

Я использую Django с MongoEngine, django-celery и MongoDB backend для сельдерея. Я в очереди одна задача. Задача состоит в том, чтобы извлечь файл из GridFS (через MongoEngine FileField), манипулировать им и вернуть его в базу данных.

Задача выполняется, как я ожидаю, без очереди. Когда я ставлю его в очередь, он конвертирует файлы, но не записывает в базу данных.

Вот соответствующая часть моего settings.py.

#These are apparently defaults that I shouldn't need
BROKER_BACKEND = 'mongodb'
BROKER_HOST = "localhost"
BROKER_PORT = 27017
BROKER_USER = ""
BROKER_PASSWORD = ""
BROKER_VHOST = ""

CELERY_RESULT_BACKEND = "mongodb" CELERY_MONGODB_BACKEND_SETTINGS = {
    "host": "localhost",
    "port": 27017,
    "database": "svg",
    "taskmeta_collection": "taskmeta", }

import djcelery djcelery.setup_loader()

Я бегу из сельдерея вот так

 $ ./manage.py celeryd -l info

Когда он запускает задачу, сельдерей говорит это

[2011-07-23 16:07:11,858: INFO/MainProcess] Got task from broker: graphics.tasks.queue_convert[dfdf98ad-0669-4027-866d-c64971bb6480]
[2011-07-23 16:07:15,196: INFO/MainProcess] Task graphics.tasks.queue_convert[dfdf98ad-0669-4027-866d-c64971bb6480] succeeded in 3.33006596565s

(без ошибок)

Вот задача.

@task()
def queue_convert(imageId):
    image=Image.objects.get(id=imageId)
    convert(image)

convert вызывает кучу других функций. По сути, он сначала читает из FileField, манипулирует этой строкой, записывает эту строку в файл, манипулирует этим файлом, записывает сгенерированные строки и файлы в другие FileFields, а затем выполняет image.save ().

Журналы Монго выглядят по-разному в зависимости от того, ставлю ли я задачу в очередь. Это то, что происходит в журналах Монго, когда я использую очередь задач.

Sat Jul 23 16:03:26 [initandlisten] connection accepted from 127.0.0.1:39065 #801
Sat Jul 23 16:03:26 [initandlisten] connection accepted from 127.0.0.1:39066 #802
Sat Jul 23 16:03:29 [initandlisten] connection accepted from 127.0.0.1:39068 #803

Это то, что происходит, когда я вызываю convert (image) напрямую вместо вызова queue_convert (image.id)

Sat Jul 23 16:07:13 [conn807] end connection 127.0.0.1:43630
Sat Jul 23 16:07:13 [initandlisten] connection accepted from 127.0.0.1:43633 #808
Sat Jul 23 16:07:13 [initandlisten] connection accepted from 127.0.0.1:43634 #809
Sat Jul 23 16:07:13 [conn808] end connection 127.0.0.1:43633

Есть идеи, что может пойти не так?

Answer 1

обновление: я подумал о проблеме, которая у вас была немного больше, и, хотя кажется, что вы решили ее за вас, я добавлю пару замечаний на случай, если у кого-то возникнет аналогичная проблема.

Mongodb явно расширяет JSON, используя вместо этого 'BSON', который добавляет двоичный файл и тип файла в список поддерживаемых типов.Я видел только «JSON» в документах по сельдерею, поэтому я предполагаю, что потребуется осторожность, чтобы использовать mongodb с сельдереем и иметь дело с расширенным набором, как кажется, вы были с изображениями.

В документах для последней версии IPYTHON для разработчиков (11.0rc4) обсуждается их распределенная рабочая система.Хотя жаргон похож на сельдерей, бэкенд может быть совсем другим.Я думаю, что сельдерей относительно гибок в отношении бэкэндов и, вероятно, обеспечивает большую безопасность, что звучит как проблема с zeromq, которая требуется для ipython.Но на стороне базы данных, система ipython была «разработана с нуля вокруг mongodb», согласно документации, и bson полностью поддерживается.Поэтому, если вас не слишком волнуют другие функции сельдерея (безопасность, база разработки, связанная с django, и многое другое, конечно), вы можете посмотреть на это.Опять же, это ни в коем случае не является строгой оценкой, которую заслуживают оба сельдерея и ipython, просто возможное лидерство;ipython также хорошо интегрируется с другими библиотеками научных вычислений, со встроенной поддержкой matplotlib и множеством примеров научных вычислений, которые могут вас заинтересовать, если вы выполняете обработку изображений и обрабатываете данные изображений как массивы или что-то еще.

Удачи

оригинальный ответ: я согласен с lazerscience - это помогло бы получить больше контекста здесь.Из-за сложности этих библиотек существует так много неизвестных.Вероятно, невозможно ответить со строгостью, ожидаемой на этом сайте.

Тем не менее, я думаю, что вы, возможно, столкнулись с проблемой сериализации.Celery требует, чтобы ваши объекты были пригодны для засолки или, по крайней мере, сериализуемы в зависимости от того, какую реализацию вы выберете (я знаю, что они также поддерживают JSON, хотя я достаточно новичок, чтобы не быть уверенным, полностью ли перекрываются Pickle и JSON).Я вижу, ваша функция принимает только целочисленный параметр, что хорошо.Но будет ли переход к gridfs означать, что вы пытаетесь засечь изображение?Конечно, вы можете манипулировать изображениями с помощью сельдерея, но я не уверен, особенно если учесть все, что происходит за таинственной функцией «конвертирования», можете ли вы случайно попытаться сериализовать что-то, кроме юникода, словаря, целого числа, числа с плавающей запятой и т.другие несколько разных объектов, которые поддерживает ваш формат.Может быть, вы извлекли путь к файлу к изображению в прошлом и манипулировали им в файле, не извлекая и не отправляя больше, чем Unicode, а теперь получили само изображение?

Если я далеко от базы, пожалуйста, сделайте мне немного расслабиться.Я отвечаю, потому что я видел ваше сообщение и здесь, и в группе пользователей mongoengine, и решил, что вы застряли и не нашли более экспертное мнение.Вы также можете перепроверить, чтобы убедиться, что у вас достаточно текущие версии программного обеспечения.В какой-то момент у меня возникла куча странных проблем с сельдереем, и я обнаружил, что они в основном были решены, когда я обновил rabbitmq.Удачи!