Celery: Сбой Celery Worker после первой задачи с TypeError: объект «NoneType» не вызывается

Ошибка повторяется в журнале, потому что рабочий демон Celery дает сбой, поэтому systemd перезапускает его.

@ask , self._quick_put как-то не определено. Должен ли бильярд проверять значение None перед вызовом, перехватывать исключение или self._quick_put никогда не должен быть None ?

Когда я меняю billiard/pool.py#L1483 на if self.threads or self._quick_put is None: , Celery больше не падает, но по какой-то причине рабочие никогда не обрабатывают никаких задач.

Более подробный вывод с уровнем логирования DEBUG:

[2016-11-27 14:48:09,875: DEBUG/MainProcess] | Worker: Preparing bootsteps.
[2016-11-27 14:48:09,877: DEBUG/MainProcess] | Worker: Building graph...
[2016-11-27 14:48:09,878: DEBUG/MainProcess] | Worker: New boot order: {Timer, Hub, Pool, Autoscaler, StateDB, Beat, Consumer}
[2016-11-27 14:48:09,889: DEBUG/MainProcess] | Consumer: Preparing bootsteps.
[2016-11-27 14:48:09,889: DEBUG/MainProcess] | Consumer: Building graph...
[2016-11-27 14:48:09,898: DEBUG/MainProcess] | Consumer: New boot order: {Connection, Agent, Events, Mingle, Tasks, Control, Gossip, Heart, event loop}
[2016-11-27 14:48:09,908: DEBUG/MainProcess] | Worker: Starting Hub
[2016-11-27 14:48:09,908: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:09,908: DEBUG/MainProcess] | Worker: Starting Pool
[2016-11-27 14:48:09,998: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:09,999: DEBUG/MainProcess] | Worker: Starting Consumer
[2016-11-27 14:48:10,000: DEBUG/MainProcess] | Consumer: Starting Connection
[2016-11-27 14:48:10,016: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="6">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.
  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,018: INFO/MainProcess] Connected to amqp://user:**@10.136.131.6:5672//
[2016-11-27 14:48:10,018: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:10,019: DEBUG/MainProcess] | Consumer: Starting Events
[2016-11-27 14:48:10,031: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="7">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,034: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:10,034: DEBUG/MainProcess] | Consumer: Starting Mingle
[2016-11-27 14:48:10,035: INFO/MainProcess] mingle: searching for neighbors
[2016-11-27 14:48:10,036: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:10,041: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:10,061: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'cluster_name': 'rabbit<strong i="8">@rabbitmq</strong>', 'product': 'RabbitMQ', 'version': '3.5.6', 'information': 'Licensed under the MPL.  See http://www.rabbitmq.com/', 'capabilities': {'authentication_failure_close': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'per_consumer_qos': True, 'basic.nack': True, 'publisher_confirms': True, 'connection.blocked': True, 'exchange_exchange_bindings': True}, 'copyright': 'Copyright (C) 2007-2015 Pivotal Software, Inc.', 'platform': 'Erlang/OTP'}, mechanisms: ['AMQPLAIN', 'PLAIN'], locales: ['en_US']
[2016-11-27 14:48:10,063: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:10,064: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,189: INFO/MainProcess] mingle: sync with 3 nodes
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="9">@worker03</strong>
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="10">@worker02</strong>
[2016-11-27 14:48:11,190: DEBUG/MainProcess] mingle: processing reply from celery<strong i="11">@worker01</strong>
[2016-11-27 14:48:11,190: INFO/MainProcess] mingle: sync complete
[2016-11-27 14:48:11,191: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,191: DEBUG/MainProcess] | Consumer: Starting Tasks
[2016-11-27 14:48:11,244: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,244: DEBUG/MainProcess] | Consumer: Starting Control
[2016-11-27 14:48:11,244: DEBUG/MainProcess] using channel_id: 2
[2016-11-27 14:48:11,246: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,251: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,251: DEBUG/MainProcess] | Consumer: Starting Gossip
[2016-11-27 14:48:11,252: DEBUG/MainProcess] using channel_id: 3
[2016-11-27 14:48:11,253: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,257: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,258: DEBUG/MainProcess] | Consumer: Starting Heart
[2016-11-27 14:48:11,259: DEBUG/MainProcess] using channel_id: 1
[2016-11-27 14:48:11,260: DEBUG/MainProcess] Channel open
[2016-11-27 14:48:11,261: DEBUG/MainProcess] ^-- substep ok
[2016-11-27 14:48:11,261: DEBUG/MainProcess] | Consumer: Starting event loop
[2016-11-27 14:48:11,264: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[0eba267c-72e4-40ea-91dd-a1a7ab17c514]
[2016-11-27 14:48:11,265: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x7ff469300950> (args:('wakatime.tasks.cache_coding_activity', '0eba267c-72e4-40ea-91dd-a1a7ab17c514', {'argsrepr': '()', 'task': 'wakatime.tasks.cache_coding_activity', 'lang': 'py', 'parent_id': '81f0c7ce-1396-496f-bf64-ae243736c845', 'timelimit': [None, None], 'root_id': '128647cc-f558-4b7d-bafc-338d186b5cfa', 'reply_to': 'e3c2b067-a058-3aa0-a3a1-384d4b917bbf', 'retries': 0, 'expires': None, 'delivery_info': {'exchange': '', 'priority': None, 'routing_key': 'cache', 'redelivered': True}, 'id': '0eba267c-72e4-40ea-91dd-a1a7ab17c514', 'correlation_id': '0eba267c-72e4-40ea-91dd-a1a7ab17c514', 'group': None, 'eta': None, 'kwargsrepr': "{'cache_projects': True, 'timeout': 15, 'user_id': UUID('d9c69ce0-f194-45a6-83cf-98f931fca8aa'), 'writes_only': False}", 'origin': 'gen3021<strong i="12">@worker02</strong>'}, '[[], {"cache_projects": true, "timeout": 15, "user_id": "d9c69ce0-f194-45a6-83cf-98f931fca8aa", "writes_only": false}, {"callbacks": null, "chain": null, "chord": null, "errbacks": null}]', 'application/json', 'utf-8') kwargs:{})
[2016-11-27 14:48:11,266: CRITICAL/MainProcess] Unrecoverable error: TypeError("'NoneType' object is not callable",)
Traceback (most recent call last):
  File "./venv/src/celery/celery/worker/worker.py", line 203, in start
    self.blueprint.start(self)
  File "./venv/src/celery/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "./venv/src/celery/celery/bootsteps.py", line 370, in start
    return self.obj.start()
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 318, in start
    blueprint.start(self)
  File "./venv/src/celery/celery/bootsteps.py", line 119, in start
    step.start(parent)
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 593, in start
    c.loop(*c.loop_args())
  File "./venv/src/celery/celery/worker/loops.py", line 47, in asynloop
    consumer.consume()
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 470, in consume
    self._basic_consume(T, no_ack=no_ack, nowait=False)
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 591, in _basic_consume
    no_ack=no_ack, nowait=nowait)
  File "./venv/lib/python3.4/site-packages/kombu/entity.py", line 737, in consume
    arguments=self.consumer_arguments)
  File "./venv/lib/python3.4/site-packages/amqp/channel.py", line 1578, in basic_consume
    wait=None if nowait else spec.Basic.ConsumeOk,
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 73, in send_method
    return self.wait(wait, returns_tuple=returns_tuple)
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 93, in wait
    self.connection.drain_events(timeout=timeout)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 464, in drain_events
    return self.blocking_read(timeout)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 469, in blocking_read
    return self.on_inbound_frame(frame)
  File "./venv/lib/python3.4/site-packages/amqp/method_framing.py", line 88, in on_frame
    callback(channel, msg.frame_method, msg.frame_args, msg)
  File "./venv/lib/python3.4/site-packages/amqp/connection.py", line 473, in on_inbound_method
    method_sig, payload, content,
  File "./venv/lib/python3.4/site-packages/amqp/abstract_channel.py", line 142, in dispatch_method
    listener(*args)
  File "./venv/lib/python3.4/site-packages/amqp/channel.py", line 1613, in _on_basic_deliver
    fun(msg)
  File "./venv/lib/python3.4/site-packages/kombu/messaging.py", line 617, in _receive_callback
    return on_m(message) if on_m else self.receive(decoded, message)
  File "./venv/src/celery/celery/worker/consumer/consumer.py", line 567, in on_task_received
    callbacks,
  File "./venv/src/celery/celery/worker/strategy.py", line 145, in task_message_handler
    handle(req)
  File "./venv/src/celery/celery/worker/worker.py", line 221, in _process_task_sem
    return self._quick_acquire(self._process_task, req)
  File "./venv/lib/python3.4/site-packages/kombu/async/semaphore.py", line 62, in acquire
    callback(*partial_args, **partial_kwargs)
  File "./venv/src/celery/celery/worker/worker.py", line 226, in _process_task
    req.execute_using_pool(self.pool)
  File "./venv/src/celery/celery/worker/request.py", line 532, in execute_using_pool
    correlation_id=task_id,
  File "./venv/src/celery/celery/concurrency/base.py", line 155, in apply_async
    **options)
  File "./venv/lib/python3.4/site-packages/billiard/pool.py", line 1487, in apply_async
    self._quick_put((TASK, (result._job, None, func, args, kwds)))
TypeError: 'NoneType' object is not callable
[2016-11-27 14:48:11,273: DEBUG/MainProcess] | Worker: Closing Hub...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Closing Pool...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Closing Consumer...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Worker: Stopping Consumer...
[2016-11-27 14:48:11,274: DEBUG/MainProcess] | Consumer: Closing Connection...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Events...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Mingle...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Tasks...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Control...
[2016-11-27 14:48:11,275: DEBUG/MainProcess] | Consumer: Closing Gossip...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Closing Heart...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Closing event loop...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Stopping event loop...
[2016-11-27 14:48:11,276: DEBUG/MainProcess] | Consumer: Stopping Heart...
[2016-11-27 14:48:11,277: DEBUG/MainProcess] | Consumer: Stopping Gossip...
[2016-11-27 14:48:11,278: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[f786fc75-0518-4893-8988-ff7f063edd12]
[2016-11-27 14:48:11,278: DEBUG/MainProcess] TaskPool: Apply <function _fast_trace_task at 0x7ff469300950> (args:('wakatime.tasks.cache_coding_activity', 'f786fc75-0518-4893-8988-ff7f063edd12', {'argsrepr': '()', 'task': 'wakatime.tasks.cache_coding_activity', 'lang': 'py', 'parent_id': '81f0c7ce-1396-496f-bf64-ae243736c845', 'timelimit': [None, None], 'root_id': '128647cc-f558-4b7d-bafc-338d186b5cfa', 'reply_to': 'e3c2b067-a058-3aa0-a3a1-384d4b917bbf', 'retries': 0, 'expires': None, 'delivery_info': {'exchange': '', 'priority': None, 'routing_key': 'cache', 'redelivered': True}, 'id': 'f786fc75-0518-4893-8988-ff7f063edd12', 'correlation_id': 'f786fc75-0518-4893-8988-ff7f063edd12', 'group': None, 'eta': None, 'kwargsrepr': "{'cache_projects': True, 'timeout': 15, 'user_id': UUID('7056644f-2564-4074-b89e-631973879f44'), 'writes_only': False}", 'origin': 'gen3021<strong i="13">@worker02</strong>'}, '[[], {"cache_projects": true, "timeout": 15, "user_id": "7056644f-2564-4074-b89e-631973879f44", "writes_only": false}, {"callbacks": null, "chain": null, "chord": null, "errbacks": null}]', 'application/json', 'utf-8') kwargs:{})
[2016-11-27 14:48:11,279: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[d5c8dc57-116c-467d-9924-e2999280c2f8]
[2016-11-27 14:48:11,280: INFO/MainProcess] Received task: wakatime.tasks.cache_coding_activity[460ef864-e482-4b0f-8580-d0095750bae6]
[2016-11-27 14:48:11,281: DEBUG/MainProcess] Closed channel #3
[2016-11-27 14:48:11,281: DEBUG/MainProcess] | Consumer: Stopping Control...
[2016-11-27 14:48:11,283: DEBUG/MainProcess] Closed channel #2
[2016-11-27 14:48:11,283: DEBUG/MainProcess] | Consumer: Stopping Tasks...
[2016-11-27 14:48:11,284: DEBUG/MainProcess] Canceling task consumer...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Mingle...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Events...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Consumer: Stopping Connection...
[2016-11-27 14:48:11,286: DEBUG/MainProcess] | Worker: Stopping Pool...
[2016-11-27 14:48:12,800: DEBUG/MainProcess] result handler: all workers terminated
[2016-11-27 14:48:12,801: DEBUG/MainProcess] | Worker: Stopping Hub...
[2016-11-27 14:48:12,801: DEBUG/MainProcess] | Consumer: Shutdown Heart...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Gossip...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Control...
[2016-11-27 14:48:12,802: DEBUG/MainProcess] | Consumer: Shutdown Tasks...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] Canceling task consumer...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] Closing consumer channel...
[2016-11-27 14:48:12,803: DEBUG/MainProcess] | Consumer: Shutdown Events...
[2016-11-27 14:48:12,804: DEBUG/MainProcess] Closed channel #1
[2016-11-27 14:48:12,805: DEBUG/MainProcess] | Consumer: Shutdown Connection...
[2016-11-27 14:48:12,806: DEBUG/MainProcess] Closed channel #1
[2016-11-27 14:48:12,807: DEBUG/MainProcess] removing tasks from inqueue until task handler finished

Это было введено в Celery 4.x, потому что понижение до 3.1.24 предотвращает трассировку.

У меня этого не происходит здесь, на Linux Python 3.4. Какие аргументы вы используете для запуска рабочего?

Кстати, _quick_put никогда не должно быть None. Это происходит при запуске или всегда после сбоя подключения?

Я пытался воспроизвести, остановив брокера во время выполнения задач, и до сих пор не удалось воспроизвести.

Всегда при запуске. Рабочие аргументы:

/opt/app/venv/bin/python /opt/app/venv/bin/celery worker --app=wakatime.celery --workdir=/opt/app --logfile=/var/log/celery/worker.log --loglevel=INFO --concurrency=50 --exclude-queues=medium,low,cache

👍 для этого. Такая же проблема, даже на 4.0.1

@ask Я могу воспроизводить это каждый раз, когда у вас есть сообщения о брокере, ожидающие обработки, когда появляется рабочий. Это часто бывает при использовании бита, как в моем случае. Если бит-сервисы подключатся к сети раньше, чем воркер, вы не сможете запустить воркера из-за проблемы, упомянутой выше. Я использую python 2.7 для всего этого и могу воспроизвести его последовательно.

Это та же ошибка, что и упомянутая в #3539.

@jmesquita , что соответствует моему сценарию, поскольку в моих очередях всегда есть ожидающие сообщения в брокере при запуске рабочих процессов.

@alanhamlett Я пытаюсь это исправить и читаю код, но я новичок в сельдерее, поэтому это может занять некоторое время. Что для меня странно, так это то, что так много людей, использующих сельдерей, а сообщения сельдерея по умолчанию ставятся в очередь для рабочих, это не взорвалось в сообществе. Заставляет меня задуматься, не злоупотребляю ли я им как-то.

Я немного покопался в коде, _quick_put назначается AsyncPool._create_write_handlers , который вызывается AsyncPool.register_with_event_loop , который вызывается celery.worker.loops.asynloop . На первый взгляд проблема заключается в том, что asynloop сначала вызывает consumer.consume() и только затем вызывает obj.register_with_event_loop , что приводит к тому, что _quick_put становится None , когда он вызывается из consume() .

Это могло бы объяснить, почему проблемы не возникают, когда в очереди нет сообщений при запуске цикла событий, поскольку тогда consume() ничего не сделает, и при следующем вызове register_with_event_loop будет звонили уже.

Я мог бы исправить это, переместив

obj.controller.register_with_event_loop(hub)
obj.register_with_event_loop(hub)

before consumer.consume() , хотя это, конечно, очень наивное (и, возможно, неправильное) исправление.

Поэтому я решил свою проблему, сделав временные сообщения celery beat, что в любом случае является моим предполагаемым поведением. Я вернусь к этому, как только у меня будет немного больше опыта работы с Celery и его кодовой базой.

@jmesquita :

Поэтому я решил свою проблему, сделав сообщения celery beat временными.

Это предотвращает возникновение ошибки. Спасибо за предложение.

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

@adewes Я протестировал предложенное вами решение, и, по крайней мере, на первый взгляд кажется, что оно решает проблему.

@adewes Можете ли вы отправить запрос на вытягивание, чтобы мы могли обсудить предлагаемое вами изменение?

Есть ли обновления по этому вопросу? Это доставляет нам сейчас большие проблемы, в том числе и в производстве. Я даже не могу протестировать локально, потому что получаю проблему TypeError . Возможно, нам придется вернуться к Celery 3.

Я не смог решить эту проблему до сих пор, также пока откатился до версии 3, надеюсь, что проблема скоро будет исправлена. @thedrow мое «быстрое решение» не привело к полному решению проблемы, поэтому я не открываю запрос на включение. Я не полностью разбираюсь в потоке данных используемых компонентов (здесь задействовано несколько библиотек), поэтому, к сожалению, я не могу сейчас отлаживать это дальше.

На самом деле я даже не уверен, что мы можем перейти на более раннюю версию, потому что, возможно, мы полагаемся на новое использование заголовков сообщений в дизайне задачи v2.

@ask - я рад поделиться с вами экраном или чем-то еще, чтобы вы могли увидеть мою точную среду, чтобы помочь в отладке, может быть, даже попробовать открыть удаленную отладку, если нам нужно. Мы находимся в затруднительном положении, потому что сделали все возможное на Celery 4 и теперь не можем запустить наших рабочих в производство.

На данный момент вы можете установить мой форк, чтобы все работало в вашей рабочей среде:

pip install -e git://github.com/alanhamlett/celery.git@73147a9da31f2932eb4778e9474fbe72f23d21c2#egg=Celery

Я только что открыл #3752, чтобы исправить это, но сначала нужно найти хороший тест, чтобы покрыть ошибку.

Большое спасибо.

Начинаю думать, что схожу с ума... Я попытался обновиться до 4.0.2 (в настоящее время на 4.0.0), и с этим обновлением внезапно self.retry() также перестал работать.

Явное указание очередей в CLI выглядит как прогулка (на 4.0.0)

Мы явно указываем очереди в CLI; у нас все еще была проблема.

В пятницу, 13 января 2017 г., в 5:35, Кароль Дулеба, [email protected]
написал:

Явное указание очередей в CLI выглядит как прогулка (на
4.0.0)

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/celery/celery/issues/3620#issuecomment-272412258 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - я вижу то же самое. Указание очередей в командной строке.
Я вижу проблему только тогда, когда в очереди есть данные. Если очереди пусты, я могу запустить воркеры, и они запустятся.

+1

Имея именно эту проблему. Кажется, единственное решение - сбросить моего брокера (что не очень хорошо для очереди).

+1

После этого # 3773, отсутствия базовых функций и чрезмерной сложности я, вероятно, заменю Celery на https://github.com/closeio/tasktiger. Кто-нибудь хочет захватить #3752? Все, что вам нужно, это написать тест, чтобы охватить проблему.

@alanhamlett Я не знал о Tasktiger, но это выглядит многообещающе. Знаете ли вы, насколько он зрелый/стабильный/надежный? Я обычно большой поклонник микрофреймворков, и теперь Celery стал огромным, с несколькими внешними зависимостями + переключением на Python3... кажется, что все выходит из-под контроля (по крайней мере, в моих развертываниях).

Учитывая, что в PR #3752 уже есть исправление, каковы планы по его выпуску? Обратите внимание, что это критическая ошибка, потому что она не позволяет любой производственной среде использовать Celery 4.x. Вы не можете допустить, чтобы работники умирали только потому, что приходят ожидающие сообщения.

Я бы тоже хотел, чтобы это объединилось

Поскольку эфемерная природа работников так важна для Celery, я не могу себе представить, что существует слишком много других проблем, заслуживающих более высокого приоритета, чем этот. Это единственное, что мешает нам перейти на Prod. Есть ли у кого-нибудь предположения о том, когда это будет рассмотрено?

@johnatron Я думал то же самое, но столкнулся с множеством других недавно появившихся ошибок в Prod. Пришлось понизить версию, что сложно, потому что спецификация обмена сообщениями несовместима между 3.x и 4.x. Также заставил меня посмотреть на альтернативы Celery, такие как tasktiger . Будьте осторожны с Celery 4.xx в Prod.

Спецификация сообщения перекрестно совместима с последней версией 3.x.

Признаюсь, я очень удивлен, что это не было рассмотрено. я использую
Вилка Алана сейчас в производстве.

В понедельник, 13 февраля 2017 г., в 14:05, Алан Хамлет, [email protected]
написал:

@johnatron https://github.com/johnatron Я тоже так думал, но
столкнулся с множеством других недавно появившихся ошибок в Prod. Пришлось понизить рейтинг,
что сложно, потому что спецификация обмена сообщениями несовместима между 3.x
и 4.х. Также заставил меня посмотреть на альтернативы Celery, такие как tasktiger.
https://github.com/closeio/tasktiger . Будьте осторожны с Celery 4.xx в
Произв.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/celery/celery/issues/3620#issuecomment-279489134 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

В свете этой досадной задержки я решил объединить некоторые исправления известных проблем с Celery 4 в git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1
Это включает в себя:

• Исправление @alanhamlett для этой проблемы
• Исправление @HealthTechDevelopers , из-за которого расписание django-celery-beat не перезагружалось

Работает нормально в производстве до сих пор

Спецификация сообщения может быть кросс-совместимой, но между версиями есть (тонкие) несовместимые различия, когда речь идет о Celery Canvas и цепочке (функция, которую мы часто используем). Значительные усилия были потрачены на то, чтобы перенести наше приложение с версии 3 на версию 4. Возвращаться было бы нехорошо.

О чудный день! Спасибо.

У меня такая же проблема с использованием Python 3.6 и сельдерея 4.0.2.

Выключаешь сельдерей, создаешь задачу, запускаешь сельдерей и сразу получаешь ошибку TypeError: 'NoneType' object is not callable . @ask , не могли бы вы рассмотреть предлагаемые исправления и слияние? Это не позволяет ранее счастливым пользователям Celery продолжать использовать Celery :(

Спасибо за ваше время, @ask!

"Microsoft Windows больше не поддерживается.

Набор тестов проходит успешно, и Celery, кажется, работает с Windows, но мы не даем никаких гарантий, поскольку не можем диагностировать проблемы на этой платформе. Если вы представляете компанию, которой требуется поддержка на этой платформе, свяжитесь с нами».
Скорее всего не исправят.

@tiptoettt это не проблема, специфичная для Windows. Я на Маке. Не могли бы вы внимательно посмотреть на все комментарии? Из-за этого разработчики откажутся от Celery. Я использовал сельдерей в течение 5 лет, и это серьезная проблема. Я собираюсь использовать более раннюю версию 3.1.25, если в ней нет этой проблемы.

Также с этой проблемой

lpiner<strong i="6">@host</strong>:~$ uname -a
Linux host 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

lpiner<strong i="9">@host</strong>:~$ celery --version
4.0.2 (latentcall)

Это строка кода, которая, кажется, вызывает проблему:

task_queues = (
    Queue('queue1_name', Exchange('default'), routing_key='default'),
    Queue('queue2_name', Exchange('default'), routing_key='general.routing_key'),
)

Удаление второй очереди приводит к исчезновению проблемы.

Насколько я понял из сообщения @ChillarAnand в celery/kombu/issues/675, эта проблема должна быть решена в версии 4.0.3, верно?

Я не видел этой проблемы с тех пор, как начал сборку с основной ветки.

8 мая 2017 г., 17:58, Виктор, [email protected] написал:

Насколько я понял от @ChillarAnand
https://github.com/ChillarAnand пост в celery/kombu#675
https://github.com/celery/kombu/issues/675 , эта проблема должна быть решена
на 4.0.3, верно?

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/celery/celery/issues/3620#issuecomment-300002736 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

Спасибо, это сработало!

У меня была такая же проблема на Celery 3.1.23 (Cipater) с использованием RabbitMQ. После долгой отладки я наконец нашел эту ветку и исправил проблему, используя версию 3.1.25. Но на самом деле это было биение головой о стену.

Та же проблема на v4.0.2 (latentcall) с несколькими очередями + пульсация.

такая же проблема для меня на обходном пути v0.4.0.2 - понижение до v3.x

v4.0.2
Для меня эта проблема является шоу-стоппер. Я не рассматриваю переход на 3.x. Я надеюсь, что новая версия будет выпущена в ближайшее время.

@ba1dr сборка от мастера. Это исправляет это для меня.

@LPiner , спасибо, это решило проблему для меня. Но это не готовое к производству решение, не так ли?

@ ba1dr не большой выбор, TBH. Либо так, либо вернуться к 3.x.
Мы используем его в производстве без проблем, но наш масштаб составляет всего несколько сотен заданий в день, ваш пробег может отличаться.

Мы скоро выпустим. См. № 4109

Пострадало и здесь. Просто ударь нас. Готов к выпуску!