Este módulo implementa un ejecutor de queue.job simple usando disparadores de ir.cron.
Está pensado para usarse en entornos donde el ejecutor de jobs habitual no puede ejecutarse, como en Odoo.sh.
A diferencia del ejecutor de jobs habitual, donde los jobs se despachan a los HttpWorkers, los jobs se procesan en los hilos de CronWorker mediante los crons del ejecutor de jobs. Esta es una decisión de diseño porque:
- Odoo.sh pone a dormir los HttpWorkers cuando no hay actividad de red
- Los HttpWorkers están pensados para el tráfico. Los usuarios no deberían pagar el precio de las tareas en segundo plano.
Por ahora, solo implementa las características más básicas del ejecutor de queue_job, en particular, ni capacidad de canal ni prioridades. Consulte el ROADMAP para más detalles.
Traducción automática al español (DeepSeek) de la descripción original de OCA, que está en inglés.
auto_awesome Qué hace este módulo
Generado por IA a partir del código · Odoo 18.0Permite a Odoo procesar trabajos en segundo plano (trabajos en cola) mediante acciones programadas en lugar de un ejecutor de trabajos dedicado, lo cual es útil en plataformas de alojamiento donde el ejecutor normal no puede ejecutarse.
Este módulo cambia cómo se ejecutan los trabajos en segundo plano en Odoo. Normalmente, los trabajos de cola son gestionados por un proceso job runner independiente. Con este módulo, son recogidos y procesados por acciones programadas (cron jobs) en su lugar.
- Una nueva casilla "Queue Job Runner" aparece en los formularios de acciones programadas cuando la acción tiene como objetivo el modelo
queue.job. Cuando está marcada, esa acción programada se trata como un job runner. - El módulo instala una acción programada llamada "Queue Job Runner" que se ejecuta una vez al día por defecto, pero también se activa automáticamente cada vez que se crea un nuevo trabajo o cuando cambia el estado o la hora programada de un trabajo.
- Los trabajos se procesan de uno en uno por orden de prioridad y fecha de creación. Si un trabajo falla, se marca como fallido; si se puede reintentar, se pospone y se intenta de nuevo más tarde.
- Después de que un trabajo finaliza, los trabajos que dependen de él se encolan automáticamente.
Este módulo solo implementa la ejecución básica de trabajos. No admite capacidad de canal ni prioridades más allá del orden básico. Está pensado para entornos como Odoo.sh donde no se puede usar el job runner habitual.
Depende de
Modelos y campos (2)
- ir.cron · amplía un modelo existentequeue_job_runner
- queue.job · amplía un modelo existente
Texto generado por IA (DeepSeek) al leer el código de la versión 18.0 en GitHub; puede contener errores, así que verifícalo en el código antes de decidir. Ver el código en GitHub
Disponibilidad por versión
Revisado: 2026-11-03Estado de confirmación: 5 confirmadas, 4 sin información de 9 versiones.
Fuentes · Odoo 15.0
Confirmado el 2026-11-03 en la rama 15.0 de OCA/queue.
terminal Instalación y uso
Documentación de OCA · Odoo 18.0Configuración
Fuente · Odoo 18.0Advertencia
No use este módulo si ya está ejecutando el runner regular queue_job.
Para el caso más sencillo, no se requiere configuración además de instalar el módulo.
Para evitar que el tiempo de espera de CPU de CronWorker detenga abruptamente el procesamiento del cron del trabajo, se recomienda lanzar Odoo con --limit-time-real-cron=0, para deshabilitar por completo el tiempo de espera de CronWorker.
Nota
En Odoo.sh, esto se hace de forma predeterminada.
La ejecución paralela de trabajos se puede lograr aprovechando múltiples registros ir.cron:
- Asegúrese de tener suficientes CronWorkers disponibles (Odoo CLI
--max-cron-threads) - Duplique el registro cron
queue_job_crontantas veces como sea necesario, hasta tener tantos registros como cron workers.
Traducción automática al español (DeepSeek) de la documentación original de OCA; los comandos y el código no se traducen. Sin información verificada en OCA: Instalación, Uso.
Las instrucciones de instalación, el paquete de distribución, las dependencias y los pasos de configuración no se muestran porque todavía no se han verificado en la documentación del módulo para ninguna versión.
Datos importados de GitHub: esta ficha refleja la última revisión del catálogo, no una consulta en directo. Verifica siempre en la documentación del módulo y en staging antes de instalar en producción.