las tareas de apio con eta larga (más de 8 horas) se ejecutan varias veces seguidas cuando se alcanza eta

Question

Estoy creando una tarea con eta que oscila entre 3 y 20 horas y cuando miro el registro del trabajador, para esta tarea , el trabajador dice "Got task from broker: ..." cada hora después de que se recibió la tarea original hasta que se alcanza el eta.

Sé que esto tiene que ver con la configuración BROKER_TRANSPORT_OPTIONS = {'visibility_timeout': X} donde X es el número en segundos.

Así que jugué con visibility_timeout y si configuré algo menos de 1 hora, entonces puedo ver al trabajador haciendo la misma tarea cada X segundos, sin embargo, cuando establezco el visibility_timeout en una X de más de 1 hora, entonces mantiene predeterminado a 1 h independientemente del tiempo que configuro.

¿Alguien más se encuentra con este problema? ¿Es este un error conocido?

Estoy usando apio 3.0.11 (Slide Chiastic) con la versión 2.4.15 del servidor Redis

Answer 1

EDIT: Cualquier consumidor de mensajes usando kombu * conectado a la misma URL Redis ayudará a restaurar los mensajes unacked, por lo debe asegurarse de que todos ellos estén configurados con el mismo valor visibility_timeout.

Un error común es comenzar la Flor controlar de esta manera:

celery flower -b redis://somewhere 

lugar de la siguiente manera:

celery -A proj flower 

ya que el primero significa que el caso de la flor no se configurará con la configuración de apio , y luego faltar BROKER_TRANSPORT_OPTIONS y la configuración visibility_timeout.

Además de esto, también debe asegurarse de que los relojes de pared estén sincronizados utilizando ntp, tal como se describe en la respuesta original a continuación.

• kombu es la biblioteca de mensajería utilizada por Celery.

respuesta original:

A pesar de que no he oído hablar de algo como esto, podría ser un error. Agregué algunas declaraciones de impresión al kombu/transport/redis.py para verificar si el visibility_timeout se configuró correctamente, y definitivamente es para mí. Sin embargo, probar que funciona con valores superiores a una hora tomará más tiempo (aproximadamente 2 horas para ser exactos) para que pueda informar en ese momento.

Mientras tanto se podía verificar que se está ajustando el visiblity_timeout correctamente añadiendo el comunicado de impresión usted mismo (por ejemplo, con el método restore_visible en el transporte Redis)

Tenga en cuenta que esta característica está utilizando marcas de tiempo, por lo que si tiene más de una máquina, es importante que los relojes estén bastante sincronizados (especialmente sin alejarse por horas). Siempre debe usar ntp en servidores en red y sincronizar regularmente.