Was using Java Timer, Then switched to ScheduledExecutorService, but my problem is not fixed. As Tasks scheduled before system time change (through ntpd) are not executed on delay specified. Have no logs for same as nothing happens :(.
using jre 1.6.0_26 64 bit in my target on 64 bit linux.
Update: ScheduledExecutorService works fine on Windows. Problem is only on 64 bit Linux based system running 64 bit JVM. It works fine on 64 bit linux running 32 bit JVM...strange. Have not found any reference of same on any blogs either.
IBM's JAVA SDK has same problem (ibm-java-sdk-7.0-0.0-x86_64-archive.bin).
I had filed defect against JDK 7139684,It was accepted but has been closed and marked duplicate of 6900441. Please vote for it , if you feel its worth to get it fixed... I have no idea why its not been fixed since more than couple of years
Here is sample code I used to test this issue:
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);
}
}
There is bug in JVM for overall scheduling during Sytem time changes backward, which also impacts very basic Object.wait & Thread.sleep methods. It becomes too risky to keep Java App running when system time switches back by even certain seconds. You never know what your Java App will end up to.
So we have decided to:
Another possibility was to move to 32bit JVM, But we are using JNI and then native libraries used on target platform are not 32bit compatible. Also from our experience 32bit JVM limits our target to 1.6G heap, which is not at all sufficient for us.
I know ours is not most elegant solution, but untill JVM is fixed or some better solution is found, there doesn't seem to be any other way.
Edited: We are also considering 1st suggestion from Chris in addition to above solution: