Trabajos y colas#

Todo lo que puede tardar en Empowerment Center (calcular un cubo, un gráfico o un mapa, renovar una lista, cargar datos externos, publicar, una consulta por la API, una entrega) se calcula como un trabajo en segundo plano, nunca mientras el navegador espera la respuesta. Esta página explica cómo viven los trabajos, cómo se reparten en colas y qué puede hacer usted con ellos.

Antes de empezar#

Para ver y terminar los trabajos de todos los usuarios necesita Administración del sistema: están en la pestaña Trabajos de la consola (véase La consola de operación).
Cada usuario ve y cancela los suyos en el panel Actividad de la barra superior de la aplicación (véase el Manual de usuario).

El ciclo de vida de un trabajo#

Ciclo de vida de un trabajo Ver a tamaño completo Ver a tamaño completo

Estado	En la consola	Qué significa
`QUEUED`	En cola	Espera en la cola de su clase a que haya un hueco.
`RUNNING`	En ejecución	Se está calculando.
`DONE`	Terminado	Ha terminado bien; su resultado está disponible para quien lo lanzó.
`FAILED`	Fallido	Ha terminado con un error, que se ve en la consola y en el historial.
`CANCELED`	Cancelado	Lo canceló quien lo lanzó, un administrador o el propio servidor (por ejemplo, porque se agotó el tiempo de un recálculo programado).

Las reglas que conviene conocer:

Todo trabajo acaba en uno de los tres estados finales, también el que se cancela en la cola sin llegar a correr y el que sufre un error grave del servidor (queda Fallido).
El resultado solo lo recoge quien lanzó el trabajo, porque está calculado con sus columnas y sus universos. Quien tiene Administración del sistema ve el trabajo y lo puede cancelar, pero no recoge su resultado.
Un trabajo corre con la identidad de quien lo envió, y con el canal por el que lo envió (su sesión, una tarea programada, una entrega, la API…), que queda en la auditoría.
El error de un fallo inesperado no enseña detalles internos: dice «Error interno al calcularlo: el detalle está en el registro del servidor». Busque en el registro la hora del fallo (véase Métricas, salud y registros).
Lo terminado se queda en memoria, con su resultado, 30 minutos (ecenter.jobs.result-ttl). Después solo queda en el historial.
El historial de trabajos se conserva 90 días (ecenter.operations.maintenance.job-history) y es de donde salen la tabla Actividad de la pestaña Trabajos, el gadget Trabajos terminados y la alerta Muchos trabajos fallidos. Cada trabajo terminado queda también en la auditoría (categoría Trabajos).

Clases y colas#

Cada trabajo es de una clase, y cada clase tiene su propia cola con un número máximo de trabajos que se calculan a la vez. Lo que no cabe espera en la cola de su clase sin quitar hueco a las demás.

Clase	En la consola	A la vez, por defecto
`CUBE`	Cubos	4
`REPORT`	Informes	4
`CHART`	Gráficos	4
`MAP`	Mapas	4
`LIST`	Listas	4
`FORM`	Formularios	4
`EXTERNAL_DATA`	Datos externos	4
`PUBLICATION`	Publicaciones	4
`LEGACY_IMPORT`	Importaciones de Empowerment Center 7	4
`API`	Consultas por la API	2
`DELIVERY`	Entregas y alertas de datos	2
`OTHER`	Otros (comprobar las alertas, volver a entregar eventos, leer el catálogo…)	4

Los límites se cambian por clase con ecenter.jobs.max-concurrent.<CLASE> y el de las demás con ecenter.jobs.default-concurrency (4):

ecenter:
  jobs:
    default-concurrency: 4
    max-concurrent:
      CUBE: 6
      API: 2
      DELIVERY: 2

Dentro de una cola, lo que pide el portal tiene prioridad sobre la aplicación de análisis y los recálculos: en la consola lleva la insignia Portal.

Importante

Cada trabajo que consulta una BD de cliente necesita una sesión del pool de esa conexión, que por defecto tiene 5 (ecenter.datasource.pool.max-size) y lo comparten todas las clases. Si sube los límites de las colas sin subir el pool, los trabajos esperarán una sesión libre y fallarán a los 15 segundos (ecenter.datasource.pool.connection-timeout) aunque haya hilos libres. Véase Solución de problemas.

Tiempos máximos#

Qué	Límite	Propiedad
Cada sentencia en la BD del cliente	5 minutos	`ecenter.querying.timeout`
Cada intento de recalcular un libro en una tarea programada	2 horas	`ecenter.scheduling.recalc-timeout`
La espera de una consulta ad hoc en la petición, antes de seguir como trabajo	30 s	`ecenter.querying.ad-hoc-wait`

Cancelar un trabajo#

Un trabajo se cancela desde la pestaña Trabajos de la consola (Terminar), desde el panel Actividad de quien lo lanzó (Cancelar) o al detener una ejecución programada.

Si está en cola, no llega a ejecutarse.
Si está en ejecución, ECenter cancela en la BD del cliente la sentencia que tenga en curso, descarta la sesión que usaba y no deja empezar otra. Quien cancela no espera a la BD: el corte se hace aparte.
No es un fallo: el trabajo queda Cancelado, no cuenta para la alerta de trabajos fallidos y una entrega o una alerta de datos canceladas no se dan por fallidas.

En Oracle sin cortes fuera de banda, una sentencia que está durmiendo o esperando un bloqueo no atiende la cancelación al momento; si no ha salido en 10 segundos, ECenter interrumpe igualmente su trabajo.

No hay terminación forzada: un hilo no se mata a medias, que dejaría memoria, bloqueos y conexiones sin liberar.

Tope de trabajos en cola por usuario#

Para que un solo usuario no deje esperando a todos los demás, cada uno puede tener como mucho 100 trabajos de una misma clase esperando en su cola (ecenter.jobs.max-queued-per-user, o ECENTER_JOBS_MAXQUEUEDPERUSER). El siguiente se rechaza:

En la aplicación, con 429 TOO_MANY_JOBS, la cabecera Retry-After: 10 y el mensaje «Ya tiene 100 trabajos de este tipo esperando en la cola: espere a que empiecen o cancele alguno desde la Actividad».
En la API de consulta y el servidor MCP, con 429 TOO_MANY_RUNNING.

Lo que lanzan en nombre de un usuario el planificador y la distribución (las tareas programadas, las entregas y las alertas de datos) no cuenta ni se rechaza. El tope es de cada instancia. Si un libro con muchos documentos lo alcanza al procesarlo entero, súbalo.

Varias instancias#

Los trabajos, sus colas y sus resultados viven en la memoria de la instancia que los calcula. Por eso:

La pestaña Trabajos de la consola enseña los de la instancia que le atiende (la de la cabecera). Las sesiones, los libros abiertos y las alertas sí son de todas.
El proxy tiene que mandar las peticiones de un mismo usuario a la misma instancia (afinidad por la cookie de sesión), o no encontrará su trabajo. Véase Instalación.
Los límites de cada cola y el tope por usuario son de cada instancia.
Los gadgets de la pestaña Actividad sí cuentan los trabajos de todas, porque salen del historial común.