name font python celery celery-task

font - subplot python title



Apio AttributeError: error asíncrono (6)

Asegúrese de que está utilizando Kombu 4.1.0. La última versión de Kombu cambia el nombre de asíncrono a asíncrono.

Tengo RabbitMQ y Celery ejecutándose localmente en mi Mac (OS / X 10.13.4), el siguiente código funciona localmente cuando ejecuto add.delay (x, y):

#!/usr/bin/env python from celery import Celery from celery.utils.log import get_task_logger logger = get_task_logger(__name__) app = Celery(''tasks'', / broker=''pyamqp://appuser:xx@c2/appvhost'', / backend=''db+mysql://appuser:xx@c2/pigpen'') @app.task(bind=True) def dump_context(self, x, y): print(''Executing task id {0.id}, args: {0.args!r} kwargs {0.kwargs!r}''.format(self.request)) @app.task def add(x, y): logger.info(''Adding {0} + {1}''.format(x, y)) return x + y

Sin embargo, cuando trato de ejecutar el trabajador de apio en un ODROID-C2 ejecutando Kali 2018.2 (con las actualizaciones actuales, recibo el siguiente error al ejecutar el celery -A tasks worker --loglevel=info :

Traceback (most recent call last): File "/usr/local/bin/celery", line 11, in <module> sys.exit(main()) File "/usr/local/lib/python2.7/dist-packages/celery/__main__.py", line 14, in main _main() File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 326, in main cmd.execute_from_commandline(argv) File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 488, in execute_from_commandline super(CeleryCommand, self).execute_from_commandline(argv))) File "/usr/local/lib/python2.7/dist-packages/celery/bin/base.py", line 281, in execute_from_commandline return self.handle_argv(self.prog_name, argv[1:]) File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 480, in handle_argv return self.execute(command, argv) File "/usr/local/lib/python2.7/dist-packages/celery/bin/celery.py", line 412, in execute ).run_from_argv(self.prog_name, argv[1:], command=argv[0]) File "/usr/local/lib/python2.7/dist-packages/celery/bin/worker.py", line 221, in run_from_argv return self(*args, **options) File "/usr/local/lib/python2.7/dist-packages/celery/bin/base.py", line 244, in __call__ ret = self.run(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/celery/bin/worker.py", line 255, in run **kwargs) File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 99, in __init__ self.setup_instance(**self.prepare_args(**kwargs)) File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 122, in setup_instance self.should_use_eventloop() if use_eventloop is None File "/usr/local/lib/python2.7/dist-packages/celery/worker/worker.py", line 241, in should_use_eventloop self._conninfo.transport.implements.async and File "/home/autossh/.local/lib/python2.7/site-packages/kombu/transport/base.py", line 125, in __getattr__ raise AttributeError(key) AttributeError: async

Desde el Kali ODROID puedo conectarme a la instancia de RabbitMQ en el host llamado c2 utilizando un script Python Pika y mysql desde ese dispositivo también funciona en la máquina c2. He encontrado errores similares, ninguna de esas soluciones ha funcionado para mí.

La versión de apio instalada en el ODROID-C2 a través de pip es:

celery --version 4.1.0 (latentcall)


El apio no fija sus requisitos para kombu y billar en versiones específicas. Requieren lo siguiente:

billiard>=3.5.0.2,<3.6.0 kombu>=4.0.2,<5.0

https://github.com/celery/celery/blob/v4.1.0/requirements/default.txt

kombu 4.2.0 fue lanzado con un cambio de ruptura y las versiones anteriores de apio lo instalan automáticamente.

Dado que el apio no fija versiones específicas, debe seguir lo siguiente si va a seguir utilizando el apio 4.1.0:

kombu==4.1.0 billiard==3.5.0.2


Ese era el problema, de hecho era la versión kombu.

''appuser'' instaladas 2 versiones de kombu, 4.2.0 como usuario ''appuser'' , en el que estaba tratando de iniciar al trabajador, y 4.1.0 como ''root'' . El 4.1.0 como ''root'' funcionaría, el otro usuario no lo hizo.

''appuser'' kombu 4.2.0 de la cuenta de usuario ''appuser'' (pip desinstala kombu como ese usuario), por lo que usaría el paquete instalado en todo el sistema, y ​​el trabajador de Apio operó correctamente bajo esa cuenta.

Para verificar que en realidad es kombu 4.2.0 lo que se rompe, eliminé la versión 4.1.0 de todo el sistema y dejé que pip instale la versión más reciente, que es la 4.2.0, y el trabajador de Apio ya no se iniciaría . Lo desinstalé y forcé a pip a instalar 4.1.0 ( pip install kombu == 4.1.0) y el trabajador funcionó correctamente.

Como otra comprobación, fui a mi Mac, donde originalmente escribí / probé este código, y verifiqué la versión de kombu instalada allí por pip: 4.1.0. No estoy seguro de por qué pip en Mac y Pi3 instaló la versión 4.1.0 de kombu, mientras que pip en ODROID-C2 instaló la versión 4.2.0. Cavaré más si tengo la oportunidad, pero ahora funciona.


Nos clasificamos simplemente actualizando al apio == 4.1.1

Parece que la última versión para el 4.1.X solucionó el cambio de nombre del módulo en kombu


Una solución rápida para hackear es deshabilitar el resultado del backend:

# CELERY_RESULT_BACKEND = ''redis://redis''