Java TimerTask behaves differently with openSuse 13.1 and 13.2

I am not certain that is the correct forum, but since programming is involved I am posting it here.
Java TimerTask behaves differently with openSuse 13.1 and 13.2 when a Java TimerTask is running and due to a suspend - resume cycle the elapsed (real) time after the resume exceeds the programmed period.
openSuse 13.1: The TimerTask fires after the resume. This is the behavior I expect, giving the software a chance to handle this situation.
openSuse 13.2: The TimerTask does not fire after the resume, but only after the CPU has elapsed. The time between suspend and resume seems to be ignored, giving the software no chance to handle this situation.

The kernel in both scenarios is 3.14.24, the jvm 1.7 or 1.8 (does not matter), so this seems to be problem of the operating environment.
I am not using kernel 3.16.6 because of a bug in the resume (see https://bugzilla.kernel.org/show_bug.cgi?id=88541), 3.14.24 being the newest kernel available to me with a working resume.
Any suggestion how to get back the “old” behavior, may be configuring openSuse 13.2 ?

Disclaimer: I am not a great programmer.

Are you using Sun/Oracle Java to run the program, or the built in OpenJDK
stuff, or something else? Have you tried using the Sun/Oracle version
rather than the built-in default OpenJDK?


Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

I am using the built-in openJDK Java runtimes. And I think they are the same for openSuse 13.1 and 13.2.
The java programm is started via a KDE desktop applet. Maybe with openSuse 13.2 some property must be set that has been a default up to openSuse 13.1?

Hi, it might be best if you showed a small example program so that I could check this. Also check whether the problem remains with the Oracle jdk. HTH Lenwolf

Hi, here a simple example.


import java.awt.Cursor;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Timer;
import java.util.TimerTask;


public class TimerTest {
	Timer refreshTimer = null;
	RefreshTask refreshTask = null;
	
	TimerTest() {
		refreshTimer = new Timer("RefreshData");
		refreshTask = new RefreshTask();
	}
	
	public void startTest() {
		refreshTimer.schedule(refreshTask, 0, 5*60000);
	}
	
	public static void main(String] args) {
		TimerTest timerTest = new TimerTest();
		timerTest.startTest();
	}

	class RefreshTask extends TimerTask {
		SimpleDateFormat dateFormat = null;
		
		RefreshTask() {
			super();
			dateFormat = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss.SS");
		}

		@Override
		public void run() {
			System.out.println("TimerTest: " + dateFormat.format(new Date()));
		}
		
	}
	

}

The result with openSuse 13.1:TimerTest: 2014.12.12 19:41:24.589
TimerTest: 2014.12.12 19:46:24.590
19:47 suspend
19:54 resume
TimerTest: 2014.12.12 19:54:44.707
TimerTest: 2014.12.12 19:59:44.707
The Timer fires directly after the resume, since the period of 5 min has expired.

The result with openSuse 13.2:
TimerTest: 2014.12.12 17:35:53.695
TimerTest: 2014.12.12 17:40:53.695
TimerTest: 2014.12.12 17:45:53.695
suspend 17:48
resume 17:55
suspend 17:56
resume 19:22TimerTest: 2014.12.12 19:23:00.694
The Timer does not fire directly after the resume, although the period of 5 min has expired.

Hi,

sorry I took such a long time to reply. I’ve tried your prog and I can indeed see the problem happening:

It seems to all intents and purposes that the timer is rescheduled to restart the delay at the time the machine is woken up - 5 minutes after that it executes.

I’ve tried it with the Oracle JDK, with different delays, and also with scheduleAtFixedRate etc, no change.

I think you should raise this as a bug.

Sorry I can’t be of more help here.

Lenwolf