Celery: Celery Worker falla después de la primera tarea con TypeError: el objeto 'NoneType' no se puede llamar

El error se repite en el registro porque el demonio trabajador de Celery se bloquea, por lo que systemd lo reinicia.

@ask , self._quick_put alguna manera no está definido. ¿Debe billar verificar un None antes de llamar, capturar la excepción, o self._quick_put nunca debe ser None ?

Cuando cambio billiard/pool.py#L1483 a if self.threads or self._quick_put is None: Celery ya no falla, pero por alguna razón los trabajadores nunca procesan ninguna tarea.

Salida más detallada con nivel de registro 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

Esto se introdujo con Celery 4.x porque la degradación a 3.1.24 evita el rastreo.

No me pasa aquí en Linux Python 3.4. ¿Qué argumentos utilizas para poner en marcha al trabajador?

_quick_put nunca debería ser Ninguno por cierto. ¿Sucede esto al inicio o siempre después de una falla de conexión?

He estado tratando de reproducir deteniendo el corredor mientras ejecutaba tareas, y todavía no he tenido suerte en la reproducción.

Siempre al inicio. Los argumentos de los trabajadores son:

/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

👍 por esto. Obteniendo el mismo problema, incluso en 4.0.1

@ask Puedo reproducirlo cada vez que tenga mensajes en el corredor esperando ser procesados ​​cuando aparezca el trabajador. Este suele ser el caso cuando se usa el ritmo, que es mi caso. Si los servicios beat se conectan antes que el trabajador, no podrá iniciar el trabajador debido al problema mencionado anteriormente. Estoy usando python 2.7 para todo lo que importa y puedo reproducirlo de manera consistente.

Este es el mismo error que el mencionado en #3539

@jmesquita eso es consistente con mi escenario, ya que mis colas siempre tienen mensajes pendientes en el intermediario al iniciar los trabajadores.

@alanhamlett Estoy tratando de solucionar esto y leyendo el código, pero soy nuevo en el apio, por lo que podría llevarme algún tiempo. Lo que es extraño para mí es que con tantas personas que usan celery y los mensajes de celery se ponen en cola de forma predeterminada para los trabajadores, esto no ha explotado dentro de la comunidad. Me hace preguntarme si lo estoy usando mal de alguna manera.

Investigué un poco en el código, _quick_put es asignado por AsyncPool._create_write_handlers , que es llamado por AsyncPool.register_with_event_loop , que es llamado por celery.worker.loops.asynloop . Superficialmente, el problema parece ser que asynloop primero llama a consumer.consume() y solo luego llama a obj.register_with_event_loop , lo que hace que _quick_put sea None cuando se llama desde consume() .

Esto explicaría por qué los problemas no ocurren cuando no hay mensajes en la cola cuando se inicia el ciclo de eventos, ya que consume() no hará nada y la próxima vez que se llame, register_with_event_loop lo hará. ya han sido llamados.

Podría arreglar esto moviéndome

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

antes consumer.consume() , aunque esto es, por supuesto, solo una solución muy ingenua (y posiblemente incorrecta).

Así que solucioné mi problema haciendo que los mensajes de celery beat fueran transitorios, lo que en realidad es mi comportamiento previsto de todos modos. Volveré a revisar esto tan pronto como tenga un poco más de experiencia con Celery y su base de código.

@jmesquita :

Así que solucioné mi problema haciendo que los mensajes de celery beat sean transitorios

Eso evita que se produzca el error. Gracias por la sugerencia.

Solo puedo reproducir este error si intento consumir de varias colas. Si todo se consume de una sola cola, el inicio funciona como se espera (los mensajes en la cola se consumen correctamente).

@adewes Probé la solución propuesta y, al menos en la superficie, parece resolver el problema.

@adewes ¿Puede emitir una solicitud de extracción para que podamos discutir su cambio propuesto?

¿Hay alguna actualización sobre este tema? Esto nos está causando grandes problemas ahora, incluso en la producción. Ni siquiera puedo probar localmente porque tengo el problema TypeError . Es posible que tengamos que volver a bajar a Celery 3.

No pude resolverlo hasta ahora, también bajé a la versión 3 por ahora, espero que el problema se solucione pronto. @thedrow mi "solución rápida" no produjo una resolución completa del problema, por lo que no estoy abriendo una solicitud de extracción. No estoy completamente versado en el flujo de datos de los componentes utilizados (hay varias bibliotecas en juego aquí), por lo que lamentablemente no puedo depurar esto más en este momento.

De hecho, ni siquiera estoy seguro de que podamos cambiar a una versión anterior porque es posible que estemos confiando en el nuevo uso de encabezados de mensajes en el diseño de tareas v2.

@ask--Estoy feliz de compartir la pantalla o lo que sea con usted para que pueda ver mi entorno exacto para ayudar a depurar, tal vez incluso intente abrir una depuración remota si es necesario. Estamos en un pequeño aprieto porque nos metimos de lleno en Celery 4 y ahora no podemos poner a nuestros trabajadores en producción.

Por ahora, puede instalar mi bifurcación para que todo funcione en su entorno de producción:

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

Acabo de abrir #3752 para arreglar esto, pero primero necesito encontrar una buena prueba para cubrir el error.

Muchas gracias.

Empezando a pensar que me estoy volviendo loco... Traté de actualizar a 4.0.2 (actualmente en 4.0.0) y con esa actualización, de repente self.retry() también dejó de funcionar.

Especificar colas explícitamente desde CLI parece un paseo (en 4.0.0)

Especificamos las colas explícitamente en la CLI; todavía teníamos el problema.

El viernes 13 de enero de 2017 a las 5:35 a. m., Karol Duleba [email protected]
escribió:

Especificar colas explícitamente desde CLI parece un paseo (en
4.0.0)

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/celery/celery/issues/3620#issuecomment-272412258 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABRHQSzvyRcQI5qvfufNwPJvXNElcQKPks5rR1NggaJpZM4K7LEz
.

@jdotjdot - Estoy viendo lo mismo. Especificación de colas en la línea de comando.
Solo veo el problema cuando hay datos en la cola. Si las colas están vacías, puedo iniciar trabajadores y se ejecutarán.

+1

Tener este problema exacto. La única solución parece ser restablecer mi corredor (que no es bueno para una cola).

+1

Después de esto, #3773, falta de funciones básicas y exceso de complejidad, probablemente reemplazaré Celery con https://github.com/closeio/tasktiger. ¿Alguien quiere hacerse cargo de #3752? Todo lo que necesita es escribir una prueba para cubrir el problema.

@alanhamlett No conocía a tasktiger, pero parece prometedor. ¿Sabes qué tan maduro/estable/confiable es? Por lo general, soy un gran admirador de los micro-frameworks, y ahora Celery se ha vuelto enorme, con varias dependencias externas + cambio a Python3... parece que las cosas se salen de control (al menos en mis implementaciones).

Teniendo en cuenta que ya hay una solución en PR #3752, ¿cuáles son los planes para lanzar esto? Tenga en cuenta que este es un error crítico porque impide que cualquier entorno de producción use Celery 4.x. No puede hacer que los trabajadores mueran solo porque están llegando mensajes pendientes.

Me gustaría ver esto fusionado también

Dado que la naturaleza efímera de los trabajadores es tan fundamental para Celery, no puedo imaginar que haya muchos otros problemas que merezcan una prioridad más alta que esta. Esto es lo único que nos impide ir a Prod. ¿Alguien por ahí tiene una estimación de cuándo se abordará?

@johnatron Pensé lo mismo, pero me encontré con muchos otros errores recientemente introducidos en Prod. Tuve que cambiar a una versión anterior, lo cual es difícil porque la especificación de mensajería no es compatible entre 3.x y 4.x. También me hizo buscar alternativas a Celery, como tasktiger . Tenga cuidado con Celery 4.xx en Prod.

La especificación del mensaje es compatible con la última versión de 3.x.

Admito que estoy bastante asombrado de que esto no se haya abordado. Estoy usando
El tenedor de Alan ahora mismo en producción.

El lunes 13 de febrero de 2017 a las 14:05, Alan Hamlett [email protected]
escribió:

@johnatron https://github.com/johnatron Pensé lo mismo, pero
se encontró con muchos otros errores recientemente introducidos en Prod. Tuve que degradar,
lo cual es difícil porque la especificación de mensajería no es compatible entre 3.x
y 4.x. También me hizo buscar alternativas al apio, como tasktiger
https://github.com/closeio/tasktiger . Tenga cuidado con Celery 4.xx en
Pinchar.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/celery/celery/issues/3620#issuecomment-279489134 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABRHQZkHixjDu37IA7PbAW6iJYcVTGevks5rcKligaJpZM4K7LEz
.

A la luz de este desafortunado retraso, decidí fusionar algunas correcciones para problemas conocidos de Celery 4 en git+http://github.com/Eugeny/celery#egg=celery==4.0.2.1
Esto incluye:

• Solución de @alanhamlett para este problema
• La corrección de @HealthTechDevelopers para el programa django-celery-beat no se vuelve a cargar

Trabajando bien en producción hasta ahora

La especificación del mensaje puede ser compatible, pero existen diferencias (sutiles) incompatibles entre las versiones cuando se trata de Celery Canvas y el encadenamiento (una característica que usamos mucho). Se hizo un esfuerzo considerable para migrar nuestra aplicación de v3 a v4. Tener que volver sería un mal momento.

¡Oh frabjoso día! Gracias.

Tengo este mismo problema usando Python 3.6 y apio 4.0.2.

Apague el apio, cree una tarea, inicie el apio e inmediatamente obtenga el error TypeError: 'NoneType' object is not callable . @ask , ¿podría considerar las correcciones propuestas y la fusión? Esto impide que los usuarios previamente felices de Celery continúen usando Celery :(

¡Gracias por tu tiempo, @ask!

"Microsoft Windows ya no es compatible.

El conjunto de pruebas está superando y Celery parece estar funcionando con Windows, pero no garantizamos que no podamos diagnosticar problemas en esta plataforma. Si usted es una empresa que requiere soporte en esta plataforma, comuníquese con nosotros".
Probablemente no se va a arreglar.

@tiptoettt este no es un problema específico de Windows. Estoy en Mac. ¿Puedes por favor mirar de cerca los comentarios de todos? Los desarrolladores abandonarán Celery debido a esto. He usado apio durante 5 años y es un problema importante. Voy a usar una versión anterior 3.1.25 si no tiene este problema.

También teniendo este problema

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)

Esta es la línea de código que parece causar el problema:

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

Eliminar la segunda cola hace que el problema desaparezca.

Por lo que entiendo de la publicación de @ChillarAnand en celery/kombu/issues/675, este problema debería resolverse con 4.0.3, ¿verdad?

No he visto este problema desde que comencé a construir desde la rama maestra.

El 8 de mayo de 2017 a las 5:58 p. m., "Victor" [email protected] escribió:

Por lo que entiendo de @ChillarAnand
https://github.com/Publicación de ChillarAnand en celery/kombu#675
https://github.com/celery/kombu/issues/675 , este problema debería resolverse
por 4.0.3, ¿verdad?

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/celery/celery/issues/3620#issuecomment-300002736 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AC3sA400hzoX7V0GUrUSfYmry9SZ8eIRks5r34_pgaJpZM4K7LEz
.

¡Gracias, funcionó!

Tuve el mismo problema en Celery 3.1.23 (Cipater) usando RabbitMQ. Después de una larga depuración, finalmente encontré este hilo y solucioné el problema usando la versión 3.1.25. Pero estaba golpeando la cabeza contra la pared, de verdad.

Mismo problema en v4.0.2 (latentcall) con múltiples colas + latido.

el mismo problema para mí en v0.4.0.2 la solución es degradar a v3.x

v4.0.2
Para mí este tema es un sensacional. No considero degradar a 3.x. Espero que la nueva versión se publique pronto.

@ ba1dr compilado desde el maestro. Eso me lo arregla.

@LPiner , gracias, esto me solucionó el problema. Pero esta no es una solución lista para producción, ¿eh?

@ ba1dr no hay muchas opciones TBH. Es esto o degradar de nuevo a 3.x.
Lo usamos en producción sin problemas, pero nuestra escala es solo de unos pocos cientos de trabajos por día, su millaje puede variar.

Vamos a lanzar pronto. Ver #4109

Afectado aquí también. Solo golpéanos. Listo para el lanzamiento!