acorde django-apio, celery.chord_unlock mantiene siempre la ejecución de no llamar a la devolución de llamada proporcionado

Question

estoy usando Django Apio con Redis para ejecutar algunas tareas como esta:

header = [ 
    tasks.invalidate_user.subtask(args = (user)), 
    tasks.invalidate_details.subtask(args = (user)) 
] 

callback = tasks.rebuild.subtask() 

chord(header)(callback) 

Así que básicamente el mismo que se indica en documentation.

Mi problema es que cuando se llama a este acorde de tarea, celery.chord_unlock la tarea sigue intentándolo para siempre. Las tareas en header finalizan correctamente, pero debido a chord_unlock que nunca se ha realizado, callback nunca se llama.

Supongo que mi problema es no poder detectar que las tareas de header han finalizado, he recurrido a la documentación para ver cómo se puede personalizar esto. He encontrado a section, describiendo cómo se implementa la sincronización, hay un ejemplo proporcionado, lo que me falta es cómo puedo llamar a esa función de ejemplo (es decir, ¿hay una señal para esto?).

Además hay una nota que este método no se utiliza con Redis backend:

Esto es usado por todos los backends de Resultados excepto Redis y Memcached, que incrementar un contador después de cada tarea en la cabecera, a continuación, la aplicación de la devolución de llamada cuando el contador excede el número de tareas en el conjunto.

Pero también dice que el enfoque Redis es mejor:

El enfoque Redis y Memcached es una solución mucho mejor

¿Qué enfoque es que? ¿Cómo se implementa?

Entonces, ¿por qué no se hace chord_unlock y cómo puedo hacer que detecte header tareas finalizadas?

que estoy usando: Django 1.4, 2.5.3 apio, apio-django 2.5.5, 2.4.12 Redis

Answer 1

No tienes un ejemplo de sus tareas, pero no tenía el mismo problema y mi solución podría aplicarse.

tuve ignore_result=True en las tareas que estaba añadiendo a una cuerda, que se define así:

@task(ignore_result=True) 

Al parecer ignorando el resultado hace que sea para que la tarea chord_unlock no sabe que son completa. Después de eliminar ignore_result (incluso si la tarea solo devuelve verdadero), el acorde llamó correctamente a la devolución de llamada.

Answer 2

que tenían el mismo error, he cambiado el corredor para RabbitMQ y chord_unlock está trabajando hasta que termine mi tarea (2-3 minutos tareas)

al utilizar Redis que finalice la tarea y chord_unlock única refritos como 8-10 veces cada 1s, por lo que la devolución de llamada no se estaba ejecutando correctamente.

[2012-08-24 16:31:05,804: INFO/MainProcess] Task celery.chord_unlock[5a46e8ac-de40-484f-8dc1-7cf01693df7a] retry: Retry in 1s [2012-08-24 16:31:06,817: INFO/MainProcess] Got task from broker: celery.chord_unlock[5a46e8ac-de40-484f-8dc1-7cf01693df7a] eta:[2012-08-24 16:31:07.815719-05:00]

... just like 8-10 times....

cambiar agente trabajó para mí, ahora estoy probando @ Chris solución y mi función de devolución de llamada nunca recibe los resultados de las subtareas de cabecera: S, por lo que, no lo hace trabajos para mí.

---

apio == 3.0.6

django == 1.4

django-apio == 3.0.6

redis == 2.6

broker: redis-2,4 .16 en Mac OS X

Answer 3

Esto podría causar un problema tal que; De la documentación;

Nota:

Si está utilizando acordes con el backend resultado Redis y reemplazando el método Task.after_return(), es necesario asegurarse de que llamar al método súper o de lo contrario la devolución de llamada acorde no lo harán se aplicado.

def after_return(self, *args, **kwargs): 
    do_something() 
    super(MyTask, self).after_return(*args, **kwargs) 

Como mi entender, Si ha sobrescrito after_return función en su tarea, se debe eliminar o al menos llamar súper uno.

Parte inferior del tema: http://celery.readthedocs.org/en/latest/userguide/canvas.html#important-notes