Celery: Celery Worker se bloque après la première tâche avec TypeError : l'objet 'NoneType' n'est pas appelable

L'erreur se répète dans le journal car le démon de travail Celery plante, donc systemd le redémarre.

@ask , self._quick_put n'est en quelque sorte pas défini. Le billard doit-il vérifier une None avant d'appeler, intercepter l'exception, ou self._quick_put ne doit-il jamais être None ?

Lorsque je change billard/pool.py#L1483 en if self.threads or self._quick_put is None: , Celery ne plante plus, mais pour une raison quelconque, les travailleurs ne traitent jamais de tâches.

Sortie plus détaillée avec le niveau de journalisation 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

Cela a été introduit avec Celery 4.x car la rétrogradation à 3.1.24 empêche le traçage.

Cela ne m'arrive pas ici sur Linux Python 3.4. Quels arguments utilisez-vous pour démarrer le travailleur?

_quick_put ne devrait jamais être None btw. Cela se produit-il au démarrage ou toujours après un échec de connexion ?

J'ai essayé de reproduire en arrêtant le courtier lors de l'exécution de tâches, et toujours pas de chance de reproduire.

Toujours au démarrage. Les arguments des travailleurs sont :

/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

👍 pour cela. Obtenir le même problème, même sur 4.0.1

@ask Je peux le reproduire à chaque fois que vous avez des messages sur le courtier en attente de traitement lorsque le travailleur se présente. C'est souvent le cas lors de l'utilisation de beat, ce qui est mon cas. Si les services de battement sont mis en ligne avant le travailleur, vous ne pourrez pas démarrer le travailleur en raison du problème mentionné ci-dessus. J'utilise python 2.7 pour tout ce qui compte et je suis capable de le reproduire de manière cohérente.

C'est la même erreur que celle mentionnée sur #3539

@jmesquita qui est cohérent avec mon scénario, puisque mes files d'attente ont toujours des messages en attente sur le courtier lors du démarrage des travailleurs.

@alanhamlett J'essaie de résoudre ce problème et de lire le code, mais je suis nouveau sur le céleri, donc cela pourrait me prendre un certain temps. Ce qui est étrange pour moi, c'est qu'avec autant de personnes utilisant du céleri et des messages de céleri mis en file d'attente par défaut pour les travailleurs, cela n'a pas explosé au sein de la communauté. Je me demande si je l'utilise mal d'une manière ou d'une autre.

J'ai creusé un peu dans le code, _quick_put est assigné par AsyncPool._create_write_handlers , qui est appelé par AsyncPool.register_with_event_loop , qui est appelé par celery.worker.loops.asynloop . Superficiellement, le problème semble être que asynloop appelle d'abord consumer.consume() et seulement ensuite appelle obj.register_with_event_loop , ce qui fait que _quick_put est None quand il est appelé depuis consume() .

Cela expliquerait pourquoi les problèmes ne se produisent pas lorsqu'il n'y a pas de messages dans la file d'attente lorsque la boucle d'événements démarre, car alors consume() ne fera rien et la prochaine fois qu'il sera appelé, register_with_event_loop le fera ont déjà été appelés.

Je pourrais résoudre ce problème en déplaçant

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

avant consumer.consume() , bien que ce ne soit bien sûr qu'une solution très naïve (et peut-être fausse).

J'ai donc contourné mon problème en rendant les messages de battement de céleri transitoires, ce qui est en fait mon comportement prévu de toute façon. J'y reviendrai dès que j'aurai un peu plus d'expérience avec Celery et sa base de code.

@jmesquita :

J'ai donc contourné mon problème en rendant les messages de battement de céleri transitoires

Cela empêche l'erreur de se produire. Merci pour la suggestion.

Je ne peux reproduire ce bogue que si j'essaie de consommer à partir de plusieurs files d'attente. Si tout est consommé à partir d'une seule file d'attente, le démarrage fonctionne comme prévu (les messages de la file d'attente sont correctement consommés).

@adewes J'ai testé votre solution proposée et au moins en surface, cela semble résoudre le problème.

@adewes Pouvez-vous émettre une demande d'extraction afin que nous puissions discuter de votre proposition de modification ?

Y a-t-il des mises à jour sur ce problème ? Cela nous pose actuellement de gros problèmes, y compris au niveau de la production. Je ne peux même pas tester localement car j'obtiens le problème TypeError . Nous devrons peut-être revenir à Celery 3.

Je n'ai pas pu le résoudre jusqu'à présent, également rétrogradé à la version 3 pour l'instant, j'espère que le problème sera bientôt résolu. @thedrow ma "solution rapide" n'a pas permis de résoudre complètement le problème, je n'ouvre donc pas de demande d'extraction. Je ne connais pas parfaitement le flux de données des composants utilisés (il y a plusieurs bibliothèques en jeu ici), donc je ne suis malheureusement pas en mesure de déboguer davantage pour le moment.

En fait, je ne suis même pas sûr que nous puissions rétrograder car il est possible que nous nous appuyions sur la nouvelle utilisation des en-têtes de message dans la conception de la tâche v2.

@ask - Je suis heureux de partager un écran ou quoi que ce soit avec vous afin que vous puissiez voir mon environnement exact pour aider au débogage, peut-être même essayer d'ouvrir un débogage à distance si nous en avons besoin. Nous sommes un peu dans le pétrin parce que nous avons tout misé sur Celery 4 et que nous ne pouvons plus démarrer nos travailleurs en production.

Pour l'instant, vous pouvez installer mon fork pour faire fonctionner les choses dans votre environnement de production :

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

Je viens d'ouvrir # 3752 pour résoudre ce problème, mais je dois d'abord trouver un bon test pour couvrir le bogue.

Merci beaucoup.

Je commence à penser que je deviens fou ... J'ai essayé de mettre à niveau vers 4.0.2 (actuellement sur 4.0.0) et avec cette mise à niveau, tout à coup, self.retry() a également cessé de fonctionner.

La spécification explicite des files d'attente à partir de la CLI ressemble à une promenade (sur 4.0.0)

Nous spécifions explicitement les files d'attente dans la CLI ; nous avions toujours le problème.

Le vendredi 13 janvier 2017 à 5h35, Karol Duleba [email protected]
a écrit:

La spécification explicite des files d'attente à partir de la CLI ressemble à une promenade (sur
4.0.0)

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/celery/celery/issues/3620#issuecomment-272412258 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - Je vois la même chose. Spécification des files d'attente sur la ligne de commande.
Je ne vois le problème que lorsqu'il y a des données dans la file d'attente. Si les files d'attente sont vides, je peux démarrer les travailleurs et ils s'exécuteront.

+1

Avoir ce problème précis. La seule solution semble être de réinitialiser mon courtier (ce qui n'est pas bon pour une file d'attente).

+1

Après cela, # 3773, manque de fonctionnalités de base et complexité excessive, je remplacerai probablement Celery par https://github.com/closeio/tasktiger. Est-ce que quelqu'un veut reprendre #3752 ? Tout ce dont vous avez besoin est d'écrire un test pour couvrir le problème.

@alanhamlett Je n'étais pas au courant de tasktiger, mais cela semble prometteur. Savez-vous à quel point il est mature/stable/fiable ? Je suis généralement un grand fan des micro-frameworks, et maintenant Celery est devenu énorme, avec plusieurs dépendances externes + passage à Python3... les choses semblent devenir incontrôlables (du moins sur mes déploiements).

Considérant qu'il existe déjà un correctif dans PR # 3752, quels sont les plans pour le publier ? Veuillez noter qu'il s'agit d'un bogue critique car il empêche tout environnement de production d'utiliser Celery 4.x. Vous ne pouvez pas faire mourir des travailleurs simplement parce que des messages en attente arrivent.

J'aimerais aussi voir cela fusionné

La nature éphémère des travailleurs étant si fondamentale pour Celery, je ne peux pas imaginer qu'il y ait trop d'autres problèmes qui méritent une priorité plus élevée que celui-ci. C'est la seule chose qui nous empêche d'aller en Prod. Quelqu'un a-t-il une estimation du moment où il sera traité?

@johnatron J'ai pensé la même chose, mais j'ai rencontré plusieurs autres bogues nouvellement introduits dans Prod. A dû rétrograder, ce qui est difficile car la spécification de messagerie n'est pas compatible entre 3.x et 4.x. M'a également fait regarder des alternatives à Celery, comme tasktiger . Soyez prudent avec Celery 4.xx dans Prod.

La spécification de message est compatible avec la dernière version de 3.x.

J'avoue que je suis assez étonné que cela n'ait pas été abordé. j'utilise
La fourchette d'Alan en ce moment en production.

Le lundi 13 février 2017 à 14h05, Alan Hamlett [email protected]
a écrit:

@johnatron https://github.com/johnatron Je pensais la même chose, mais
a rencontré plusieurs autres bogues nouvellement introduits dans Prod. J'ai dû rétrograder,
ce qui est difficile car la spécification de messagerie n'est pas compatible entre 3.x
et 4.x. M'a aussi fait regarder des alternatives au céleri, comme tasktiger
https://github.com/closeio/tasktiger . Soyez prudent avec Celery 4.xx dans
Prod.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/celery/celery/issues/3620#issuecomment-279489134 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

À la lumière de ce retard malheureux, j'ai décidé de fusionner quelques correctifs pour les problèmes connus de Celery 4 dans git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1
Ceci comprend:

• Le correctif de @alanhamlett pour ce problème
• Le correctif de @HealthTechDevelopers pour le calendrier django-celery-beat n'est pas rechargé

Fonctionne bien en production jusqu'à présent

La spécification de message peut être compatible, mais il existe des différences (subtiles) incompatibles entre les versions en ce qui concerne Celery Canvas et le chaînage (une fonctionnalité que nous utilisons beaucoup). Des efforts considérables ont été déployés pour porter notre application de la v3 à la v4. Devoir y retourner serait un mauvais moment.

Ô fabuleuse journée ! Merci.

J'ai ce même problème en utilisant Python 3.6 et le céleri 4.0.2.

Arrêtez le céleri, créez une tâche, démarrez le céleri et obtenez immédiatement l'erreur TypeError: 'NoneType' object is not callable . @ask pourriez-vous s'il vous plaît considérer les correctifs proposés et la fusion ? Cela empêche les utilisateurs auparavant satisfaits de Celery de continuer à utiliser Celery :(

Merci pour votre temps, @ask!

"Microsoft Windows n'est plus pris en charge.

La suite de tests passe et Celery semble fonctionner avec Windows, mais nous ne donnons aucune garantie car nous ne sommes pas en mesure de diagnostiquer les problèmes sur cette plate-forme. Si vous êtes une entreprise nécessitant une assistance sur cette plate-forme, veuillez nous contacter."
Il ne sera probablement pas réparé.

@tiptoettt ce n'est pas un problème spécifique à Windows. Je suis sur Mac. Pouvez-vous s'il vous plaît regarder attentivement les commentaires de chacun? Les développeurs abandonneront Celery à cause de cela. J'utilise le céleri depuis 5 ans et c'est un problème majeur. Je vais utiliser une version antérieure 3.1.25 si elle n'a pas ce problème.

Ayant aussi ce problème

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)

C'est la ligne de code qui semble causer le problème :

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

La suppression de la deuxième file d'attente entraîne la disparition du problème.

D'après ce que j'ai compris du message de @ChillarAnand dans celery/kombu/issues/675, ce problème devrait être résolu d'ici la 4.0.3, n'est-ce pas ?

Je n'ai pas vu ce problème depuis que j'ai commencé à construire à partir de la branche master.

Le 8 mai 2017 à 17h58, "Victor" [email protected] a écrit :

D'après ce que je comprends de @ChillarAnand
https://github.com/ChillarAnand's post in celery/kombu#675
https://github.com/celery/kombu/issues/675 , ce problème devrait être résolu
par 4.0.3, non ?

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/celery/celery/issues/3620#issuecomment-300002736 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

Merci, ça a marché !

J'ai eu le même problème sur Celery 3.1.23 (Cipate) en utilisant RabbitMQ. Après un long débogage, j'ai finalement trouvé ce fil et résolu le problème en utilisant la version 3.1.25. Mais c'était vraiment se cogner la tête contre le mur.

Même problème sur v4.0.2 (latentcall) avec plusieurs files d'attente + pulsation.

même problème pour moi sur v0.4.0.2 la solution de contournement est rétrogradée à v3.x

v4.0.2
Pour moi, ce problème est un écueil. Je n'envisage pas de rétrograder vers 3.x. J'espère que la nouvelle version sortira bientôt.

@ba1dr construit à partir du maître. Cela me corrige.

@LPiner , merci, cela a résolu le problème pour moi. Mais ce n'est pas une solution prête pour la production, hein ?

@ ba1dr pas beaucoup de choix TBH. C'est soit ceci, soit une rétrogradation vers 3.x.
Nous l'utilisons en production sans problème, mais notre échelle n'est que de quelques centaines de travaux par jour, votre kilométrage peut varier.

Nous allons sortir bientôt. Voir #4109

Affecté ici aussi. Frappez-nous. Prêt pour la sortie !