Programador Java que es completamente independiente de los cambios de hora del sistema.

timer 32bit-64bit

Question

Estaba usando el temporizador de Java, luego se cambió a ScheduledExecutorService, pero mi problema no se ha solucionado. Como las tareas programadas antes del cambio de hora del sistema (a través de ntpd) no se ejecutan en el retraso especificado. No tienen registros para lo mismo que nada sucede :(.

utilizando jre 1.6.0_26 64 bits en mi destino en Linux de 64 bits.

Actualización: ScheduledExecutorService funciona bien en Windows. El problema es solo en un sistema basado en Linux de 64 bits que ejecuta una JVM de 64 bits. Funciona bien en Linux de 64 bits ejecutando JVM de 32 bits ... extraño. Tampoco he encontrado ninguna referencia del mismo en ningún blog.

El JAVA SDK de IBM tiene el mismo problema (ibm-java-sdk-7.0-0.0-x86_64-archive.bin).

Había presentado un defecto contra JDK 7139684 , se aceptó pero se cerró y se marcó el duplicado de 6900441 . Por favor, vote por él, si cree que vale la pena repararlo ... No tengo idea de por qué no se ha corregido desde hace más de un par de años.

Aquí está el código de muestra que usé para probar este problema:

package test;

import java.io.IOException;
import java.util.Date;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;

/**
 * @author yogesh
 *
 */
public class TimerCheck  implements Runnable {

    ScheduledExecutorService worker;


    public TimerCheck(ScheduledExecutorService worker) {
        super();
        this.worker = worker;
        this.worker.schedule(this, 1, TimeUnit.SECONDS);
    }

    private static void update() {
        System.out.println("TimerCheck.update() "+new Date(System.currentTimeMillis()));
    }

    @Override
    public void run() {
            update();
            worker.schedule(this, 1, TimeUnit.SECONDS);
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        ScheduledExecutorService worker = Executors.newScheduledThreadPool(1);
        new TimerCheck(worker);
    }

}

Answer 1

Hay un 6900441 para la programación general durante los cambios de tiempo de Sytem hacia atrás, lo que también afecta a los métodos muy básicos de Object.wait & Thread.sleep. Es demasiado arriesgado mantener la aplicación Java en ejecución cuando la hora del sistema cambia incluso en ciertos segundos. Nunca sabes en qué terminará tu aplicación Java.

Así que hemos decidido:

• Escriba el script de watch dog (no Java :)) para verificar el cambio de hora.
• Si el tiempo cambia por cierta cantidad, cierre y reinicie la aplicación Java.

Otra posibilidad era pasar a la JVM de 32 bits. Pero estamos usando JNI y luego las bibliotecas nativas utilizadas en la plataforma de destino no son compatibles con 32 bits. Además, desde nuestra experiencia, la JVM de 32 bits limita nuestro objetivo a un montón de 1.6G, lo que no es suficiente para nosotros.

Sé que la nuestra no es la solución más elegante, pero hasta que se solucione la JVM o se encuentre una solución mejor, no parece haber otra forma.

Editado: También estamos considerando la 1ra sugerencia de Chris además de la solución anterior:

• Configure NTP para que nunca tenga un gran salto de tiempo. Sólo perdí el tiempo lentamente. Solo aplique grandes saltos de forma manual durante el tiempo de inactividad.

Answer 2

Trabajé contra el mismo problema y no he encontrado una solución. Miré a Quartz y todos los métodos JRE incorporados. Los métodos de nanotiempo pueden usar relojes monotónicos por CPU, pero creo que corres el riesgo de grandes saltos si los hilos se migran a otra CPU. Mis conclusiones fueron las siguientes:

1. Configure NTP para que nunca tenga un gran salto de tiempo. Sólo perdí el tiempo lentamente. Solo aplique grandes saltos de forma manual durante el tiempo de inactividad.
2. Use varios tiempos de espera más cortos y requiera dos tiempos de espera para declarar muerta una máquina remota. Esto no ayudará si solo tiene un sistema de temporización, pero puede ayudar con múltiples sistemas
3. Use una máquina remota a propósito para enviarle activaciones periódicas. Si su propio reloj retrocede entre las activaciones, entonces sabe que todos los temporizadores se dispararán tarde.

Básicamente, esto es un gran dolor, pero no hay balas de plata.