SchedulerX:Preguntas frecuentes sobre trabajos

La aplicación Spring no encuentra un bean

1. En la página Application Management, compruebe el modo de inicio de la máquina conectada. Asegúrese de que el modo sea Spring o Spring Boot.

2. Inyecte JobProcessor como un bean; por ejemplo, agregando la anotación @Component.

3. Revise las dependencias de su POM. Si el proyecto depende de spring-boot-devtools, debe excluirlo.

4. Si la clase JobProcessor o el método process utilizan anotaciones de programación orientada a aspectos (AOP), actualice el agente de SchedulerX a la versión más reciente. Las versiones anteriores no admiten AOP.

5. Una capa de proxy adicional puede provocar una discrepancia en el tipo de bean. Para solucionarlo, establezca un punto de interrupción en la clase DefaultListableBeanFactory. La variable miembro beanDefinitionNames enumera todos los beans registrados en Spring. Revise esta lista para determinar si un bean tiene un proxy de un aspecto inesperado, lo cual puede ocurrir si se importa indirectamente una biblioteca de terceros defectuosa. Excluya la biblioteca para resolver el problema.

En el registro de ProxyFactory, se observa que TrackerInterceptorFilter actúa como un proxy AOP adicional, lo que causa una discrepancia en el tipo de bean:

org.springframework.aop.framework.ProxyFactory: 1 interfaces [com.alibaba.schedulerx.worker.processor.JobProcessor]; 1 advisors [org.springframework.aop.support.DefaultPointcutAdvisor: pointcut [Pointcut.TRUE]; advice [com.alibaba.onetouch.tracker.filter.TrackerInterceptorFilter@7dc779bb]]; targetSource [SingletonTargetSource for target object [com.alibaba.onetouch.lc.dts.presentation.LcForexMessageRedoJob@11087483]]; proxyTargetClass=false; optimize=false; opaque=false; exposeProxy=false; frozen=false

Si las soluciones anteriores no resuelven el problema, depure el método ThreadContainer.start. Si ocurre un error class.forName para una clase que sí existe, es probable que haya una inconsistencia en el cargador de clases. Esto puede suceder si su aplicación utiliza ciertos frameworks. Para resolverlo, especifique el cargador de clases correcto llamando a SchedulerxWorker.setClassLoader.

El trabajo falla con el error "Unable to make field private"

Los trabajos MapReduce utilizan frameworks de serialización y deserialización. A partir de Java 9, el acceso reflexivo a campos privados debe habilitarse explícitamente. Agregue el siguiente parámetro a sus argumentos de JVM:

--add-opens java.base/java.lang=ALL-UNNAMED

El trabajo falla con el error "submit jobInstanceId to worker timeout"

Si este error ocurre ocasionalmente o durante un despliegue de aplicación, puede ignorarlo.

Si el error persiste y workerAddr en el mensaje de error siempre apunta a la misma máquina, significa que se desconectó la conexión persistente entre el servidor y el agente. Para resolver este problema, reinicie el nodo worker afectado o actualice el agente de SchedulerX a la versión más reciente. Después de una actualización, una conexión persistente desconectada puede recuperarse automáticamente.

El trabajo falla con el error "used space beyond 90.0%!"

El disco está lleno. Libere espacio en el disco de su instancia ECS o contenedor.

El trabajo falla con el error "ClassNotFoundException"

Este error indica que no se encontró la clase en el nodo worker que ejecuta el trabajo. Utilice el nombre de clase totalmente calificado para el Processor del trabajo Java, no el nombre simple.

Si el nombre de clase jobProcessor configurado es correcto, entonces la clase no está presente en el nodo worker. Este problema suele deberse al despliegue de un paquete incorrecto o a la conexión de la aplicación con la máquina de otro usuario. Puede iniciar sesión en el nodo worker y usar un descompilador para investigar.

El trabajo falla con el error "jobInstance=xxx don't update progress more than 60s"

Si un nodo worker que ejecuta un trabajo deja de funcionar o está en proceso de despliegue y no reporta su progreso durante más de 60 segundos, el servidor finaliza forzosamente la instancia del trabajo. Si confirma que el nodo worker causó el problema o que dicho nodo ya no existe, puede ignorar este error.

El trabajo falla sin mensaje de error

Síntoma:

El trabajo falla, pero no se muestra ningún mensaje de error.

Posibles causas:

Esto puede deberse a un fallo en la máquina o a un error en la lógica de negocio.

Solución:

• Vaya a la página Execution List y seleccione la pestaña Task Instance List. Busque la instancia de trabajo fallida y haga clic en Details en la columna Operation para ir a la página Task Instance Details e identificar la máquina donde ocurrió el fallo.

  Si no hay detalles de tareas disponibles, significa que es un trabajo independiente. En este caso, busque workerAddr en la sección de información básica para identificar la máquina que ejecutó el trabajo.

• Inicie sesión en la máquina y abra el archivo ~/logs/schedulerx/worker.log.

  Ejecute el comando grep <Instance ID> worker.log para ver los registros relacionados con la instancia del trabajo. Si existe una excepción de nivel ERROR, revise el seguimiento de pila para encontrar la causa específica.

• Si la descripción del error está vacía, es probable que el fallo se origine en su lógica de negocio, la cual no reportó ningún error. En este caso, investigue primero su lógica de negocio.

• Si la descripción del error indica una excepción del framework, póngase en contacto con el soporte técnico de SchedulerX uniéndose al grupo de DingTalk (ID: 23103656).

Investigar un fallo de trabajo

• Para un trabajo independiente que lanza una excepción, vaya a la página Execution List y haga clic en la pestaña Task Instance List. En la columna Operation de la instancia de trabajo fallida, haga clic en Details para ver el mensaje de error.

• Si el trabajo no lanza una excepción o si es un trabajo distribuido, puede utilizar Log Service para solucionar el problema si utiliza la Professional Edition.

• Si utiliza la Basic Edition, puede iniciar sesión en el nodo worker y revisar los registros de SchedulerX y los registros de su aplicación para solucionar el problema.

Trabajo atascado en estado Running

Síntoma:

Un trabajo programado permanece en estado Running y no finaliza.

Posibles causas:

• Un problema en su lógica de negocio.

• Un problema en SchedulerX.

Solución:

Si el problema está relacionado con su lógica de negocio, utilice los siguientes métodos para solucionarlo. Para otros problemas, póngase en contacto con el soporte técnico de SchedulerX uniéndose al grupo de DingTalk (ID: 23103656).

• Professional Edition: Utilice la función View Stack Trace en la consola para examinar el seguimiento de pila de la excepción del trabajo. Esta función está disponible para versiones del agente 1.4.2 y posteriores.

• Basic Edition: Inicie sesión en el nodo worker atascado y ejecute el comando jstack para ver el seguimiento de pila.

  jstack <pid> | grep <job instance id> -A 20

  El siguiente ejemplo de salida muestra el seguimiento de pila del hilo:

  $jstack 29191 |grep 58903617 -A 200
  
  "Schedulerx-Container-Thread-58903617-0" #4093 prio=5 os_prio=0 tid=xxx               nid=xxx    waiting on condition [0x00002ad443101000]
     java.lang.Thread.State: WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x000000072b837ae0> (a java.util.concurrent.CountDownLatch$Sync)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
  at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
  at com.aliyun.ticket.importworker.WOImportJob.startImport(WOImportJob.java:353)
  at com.aliyun.ticket.importworker.WOImportJob.doImportForAll(WOImportJob.java:242)
  at com.aliyun.ticket.importworker.WOImportJob.process(WOImportJob.java:163)
  at com.alibaba.schedulerx.worker.container.ThreadContainer.start(ThreadContainer.java:90)
  at com.alibaba.schedulerx.worker.container.ThreadContainer.run(ThreadContainer.java:60)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  at java.lang.Thread.run(Thread.java:756)
  
  "Container-Batch-Statues-Retrieve-Thread-58903617" #4092 prio=5 os_prio=0 tid=xxx               nid=xxx    waiting on condition [0x00002ad44fe0e000]
     java.lang.Thread.State: TIMED_WAITING (sleeping)
  at java.lang.Thread.sleep(Native Method)
  at com.alibaba.schedulerx.worker.batch.BaseReqHandler$2.run(BaseReqHandler.java:74)
  at java.lang.Thread.run(Thread.java:756)
  
  "TDDL-Druid-ConnectionPool-DestroyScheduler--2-thread-237" #4052 daemon prio=5 os_prio=0 tid=xxx               nid=xxx    waiting on condition [0x00002ad462e00000]
     java.lang.Thread.State: TIMED_WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x00000007436c7190> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
  at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:1129)
  at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(ScheduledThreadPoolExecutor.java:809)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

Solucionar ejecución lenta de trabajos

Habilite la Professional Edition y utilice el rastreo distribuido. Para obtener más información, consulte How to enable distributed tracing.

Se alcanzó el límite de instancias de trabajo

Síntoma:

En la página Task Management, hace clic en Run Once y recibe el siguiente mensaje de error: The number of running job instances has reached the job concurrency limit. Please try again later.

Posibles causas:

• Ya se está ejecutando una instancia del trabajo.

• El número de instancias de trabajo en ejecución ha alcanzado la concurrencia máxima configurada para el trabajo.

Solución:

Si la concurrencia configurada es adecuada, no se requiere ninguna acción. Puede ver las instancias de trabajo en ejecución yendo a la página Task Management y haciendo clic en More > Execution History.

Si la concurrencia no es adecuada, haga clic en Edit en la columna Actions del trabajo objetivo. En la sección Advanced Configuration, establezca la instance concurrency.

El trabajo no finaliza antes de la siguiente ejecución

De forma predeterminada, la concurrencia de instancias es 1, lo que significa que los trabajos se ejecutan en serie. Si un trabajo de larga duración no ha terminado para su siguiente hora programada, SchedulerX descarta la nueva instancia de trabajo en lugar de ponerla en cola.

Si establece la concurrencia de instancias en 2, puede iniciarse una nueva instancia de trabajo incluso si la anterior no ha terminado. Pueden ejecutarse simultáneamente hasta dos instancias de trabajo como máximo.

Crear un trabajo único

SchedulerX 2.0 permite crear trabajos únicos. Para ello, establezca el tipo de tiempo en one_time. Los trabajos únicos no conservan ningún historial de ejecución.

Ver historial de ejecución de trabajos únicos

Para evitar la acumulación de datos, SchedulerX destruye automáticamente un trabajo one-time después de su ejecución y no conserva historial. Si necesita mantener un historial, habilite Log Service para conservar los registros de ejecución de todos los trabajos durante las últimas dos semanas. Esto puede ayudar a solucionar problemas. Para obtener información sobre cómo habilitar Log Service, consulte Application Management.

Configurar programación a nivel de segundos

SchedulerX admite la programación a nivel de segundos. Los tipos de tiempo cron y fix_rate no admiten esta función. Puede seleccionar el tipo de tiempo second_delay, que ejecuta el trabajo un número especificado de segundos después de que finalice la ejecución anterior.

Trabajo no programado a una hora específica

Si un trabajo independiente no se programa a una hora específica, compruebe si hay máquinas en la lista de máquinas y si todas están ocupadas. Si no hay máquinas disponibles o todas están ocupadas, solucione el problema según corresponda. Para obtener más información, consulte No worker available y What to do if all workers are busy.

Configure una alerta para cuando no haya máquinas disponibles para un trabajo. Para obtener más información, consulte Task Management.

Configurar tiempo de espera para un trabajo

SchedulerX permite configurar un tiempo de espera para todo el trabajo, pero no para tareas individuales dentro del mismo. Puede modificar dinámicamente el período de tiempo de espera en la consola. Para obtener más información, consulte Task Management.

La instancia de trabajo continúa ejecutándose después de detenerse

Síntoma:

Una instancia de trabajo continúa ejecutándose después de haber sido detenida.

Posible causa:

Cuando detiene una instancia de trabajo, SchedulerX envía una señal de finalización al agente. Tras recibir la señal, el agente deja de asignar nuevas tareas, deja de ejecutar tareas pendientes y destruye el contexto de la instancia y todos sus grupos de hilos. Sin embargo, el agente no detiene inmediatamente las tareas que ya están en curso; solo interrumpe sus hilos, por lo que las tareas continúan ejecutándose hasta completarse.

Solución:

• Generalmente, no se requiere ninguna acción. Espere a que finalicen las tareas en ejecución.

• Si necesita finalizar inmediatamente todas las tareas en ejecución cuando se detiene una instancia, debe modificar su lógica de procesamiento de tareas para manejar el estado de interrupción del hilo.

Uso de configuraciones avanzadas de trabajo

Para obtener más información, consulte Advanced configuration parameters for Task Management.

Todos los workers están ocupados

Puede ver las instancias en la página Application Management para localizar los nodos worker ocupados. Luego, haga clic en Busy para ver las métricas que han superado sus umbrales.

Puede configurar los umbrales de ocupación en la página Application Management haciendo clic en Edit Application Group.

La sección Instance Busy Configuration contiene los siguientes umbrales:

• load5: El valor predeterminado es 0

• Memory usage: El valor predeterminado es 90%

• Disk usage: El valor predeterminado es 95%

• Trigger busy status: Habilitado de forma predeterminada

Si un nodo worker está ocupado debido a una carga alta y utiliza un despliegue en Kubernetes, es posible que deba configurar los siguientes dos parámetros. De lo contrario, la utilización de CPU recopilada podría ser inexacta. Para obtener más información, consulte Connect a Spring Boot application to SchedulerX.

Habilitar rastreo distribuido

La programación de trabajos admite rastreo distribuido de extremo a extremo. Para obtener más información, consulte How to enable distributed tracing.

Trabajo atascado o lento durante el despliegue

Síntoma:

Durante el despliegue de una aplicación, un trabajo se atasca o se vuelve lento.

Posible causa:

En un trabajo distribuido, si una máquina que está procesando tareas se desconecta, el sistema redistribuye sus tareas. Luego, el sistema sondea para comprobar si hay máquinas en línea, lo que puede ralentizar todo el proceso.

Solución:

Actualice el agente a la versión más reciente. Las versiones del agente 1.7.9 y posteriores incluyen optimizaciones para este comportamiento.

Solicitud de parámetros de instancia para "Run Once"

En la página Task Management, puede hacer clic en Run Once en la columna Operation para ejecutar un trabajo programado una sola vez. El campo instance parameters en el cuadro de diálogo es opcional y se utiliza principalmente para pruebas.

El cuadro de diálogo también contiene el campo Specify Machine. Puede usar la lista desplegable para seleccionar la instancia que se ejecutará. Nota: Los parámetros de instancia no anulan los parámetros del trabajo.

Parámetros de instancia vs. parámetros de trabajo

Los parámetros de instancia y los parámetros de trabajo son conceptos diferentes. Los parámetros que recupera su código dependen de su lógica de negocio.

Recuperar parámetros de trabajo o de instancia

Para más detalles, consulte el siguiente código:

@Component
public class JavaDemoProcessor extends JavaProcessor {

    private static final Logger LOGGER = LoggerFactory.getLogger("schedulerxLog");

    @Override
    public ProcessResult process(JobContext jobContext) throws InterruptedException {

        LOGGER.info(JSON.toJSONString(jobContext));
        // Retrieve the job parameters.
        String jobParameters = jobContext.getJobParameters();
        // Retrieve the instance parameters.
        String instanceParameters = jobContext.getInstanceParameters();
        LOGGER.info("Job parameters: " + jobParameters);
        LOGGER.info("Instance parameters: " + instanceParameters);
        return new ProcessResult(InstanceStatus.SUCCESS);
    }

}

Alternativa de parámetros de instancia a parámetros de trabajo

Para más detalles, consulte el siguiente código:

@Component
public class JavaDemoProcessor extends JavaProcessor {

    private static final Logger LOGGER = LoggerFactory.getLogger("schedulerxLog");

    @Override
    public ProcessResult process(JobContext jobContext) throws InterruptedException {
        String params;
        if (StringUtils.isNotBlank(jobContext.getInstanceParameters())) {
            params = jobContext.getInstanceParameters();
        } else {
            params = jobContext.getJobParameters();
        }
        LOGGER.info("JavaDemoProcessor params:{}", params);
        return new ProcessResult(InstanceStatus.SUCCESS);
    }

}