Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

New Developer
Posts: 8
Registered: ‎02-19-2009
My Device: Blackberry 8800
Accepted Solution

Scheduled Timer - Trying to catch up ?

[ Edited ]
JDE 4.2.1 (Test device 8310 running 4.2.2). 
Hi, Has anyone experienced issues with using a regular scheduled timer (see code snippet below).
We noticed today that if the system Date/Time is changed (forwards), the timer suddenly starts firing over and over again (almost as if it trying to play catchup). Likewise if the system DateTime is set back, the timer ceases to fire (and presumably will not do so until the next 'scheduled' execution is reached.

private final static int HEARTBEAT_TIME_MILLISECONDS = 10000;



new TimerTask(){

public void run(){

SystemLog.log(SystemLog.DEBUG, "LnpClient: Injecting heartbeat job");

IClientJob job = new HeartBeatJob();







We assume that the 'next execution' time is stored as a calculated datetime and that if on checking this to be passed, the scheduler fires the timer, and then simply adds the timer increment to the date stored. Resulting in the timer immediately firing again until it has caught up.


If our assumtion is correct, sheduled timer tasks are potentially dangerous (in our case firing so frequently the device locked).  

We plan to refactor our code to use a thread based timer with a notify based wait /sleep to get around this.
Hence, this is more of a warning to other developers who might encounter similar.
Any observations on this welcome.
Message Edited by Stimmo on 22-07-2009 06:15 PM
Message Edited by Stimmo on 22-07-2009 06:19 PM
Posts: 1,123
Registered: ‎02-10-2009
My Device: 8130 / 8350 / 9530 / 9550 / 9850 / PlayBook
My Carrier: Verizon

Re: Scheduled Timer - Trying to catch up ?

The documentation states that if a scheduled execution time is missed, it will fire successively to try and catch up. So I would assume your observations are correct, as the only way to check the next execution would be to store the last time fired. If you don't need an apparent constant execution interval, a thread would probably be the best way to go since it is time independent to a certain extent. But even with a thread you will need to check the last time fired if you are doing time based intervals unless you just sleep for a certain period after each execution.
New Developer
Posts: 8
Registered: ‎02-19-2009
My Device: Blackberry 8800

Re: Scheduled Timer - Trying to catch up ?

Many thanks CMY.


Just reviewed the documentation again and it does clearly call this behaviour out - so note to self, double check. In our case, as we are only after a regular, periodic 'heartbeat', and given that small variations do not matter, sleep will probably suffice.


Thanks again.