"Original" Timer and system time (cont.)

Additional Problem handling:

--------------------------------------------------------------------------------

13) Some processing outside the timer
A) in the window environment, the timer notifies the timing task that a time-lapse error of 1 milliseconds is possible, and the Linux environment has a similar situation, but the error frequency is much lower (just 1 milliseconds before and after the specified point in time, the heartbeat step is not bad)
Possible effects:
For the task per second, 10:00:00.000 Taska, 10:00:00.999 taskb, 10:00:02.000 TASKC, 10:00:03.001 TASKD
Causes the 2nd task (TASKB) to be lost because the step size is 1 seconds + erase millisecond calculation
Code Solutions:
The timer initial time is set to xx:xx:xx:500, starting at two seconds in the middle segment as the starting point, so the error 1 milliseconds, erase milliseconds does not affect the normal timer execution

    Calendar cal = calendar.getinstance ();     int Millis = cal.get (calendar.millisecond);     int delay = (1500-millis)%;        // start running in the next 0.5 seconds (timer will occasionally be 1 milliseconds            before and after error)    Timerservice.scheduleatfixedrate (new Runnable () {:}, Delay, timer_step, timeunit.milliseconds);

b) The thread pool starts, it will probably delay 200 milliseconds before the heartbeat starts.

Not much of a bad influence
c) The heartbeat time point is not xx:xx:xx:500, normal situation does not have the problem.
The problem is that the server system time is synchronized hourly, which may still cause the heartbeat time to be on the xx:xx:xx:000, causing problem a), of course, the probability is very low.
You can consider a heartbeat that is 100 milliseconds long.
d) The task execution interface passes in the current time as a parameter
Timer (heartbeat) thread, timed to select the task that meets the execution criteria, and throw it to the task pool to execute.
Because the task execution time is too long, the task lock, the thread pool resource is insufficient and so on the condition causes the task internal log time does not meet the request is the task itself the thing, anyway the timer notifies you, does not have the tangle timer question
e) Task has a unique ID that prevents the task from being added repeatedly, one-time task without ID
Task base class to handle the ID, add a unified prefix, convenient log tracking

Scheduled Task optimization:

--------------------------------------------------------------------------------

14) Now the timer function is completed: I notify you at the specified time to do the assigned task. But there are always some strange tasks that are inconvenient to express in such a simpler language.
For example, the number of people online is counted every 10 minutes.
The current interface can be handled, but it feels very awkward:

        Regperhourtask (0, 0, Taska);        Regperhourtask (ten, 0, Taska);        Regperhourtask (0,Taska);        Regperhourtask (0,Taska);        Regperhourtask (0,Taska);        Regperhourtask (0, Taska);

And of course you can try

        New Task () {            executes 1 times every 10 times, ignoring 9        });

so I abstracted out a fixed-minute task, and you told me you were going to do it in a few minutes and then implement my execution interface.

This creates a new problem, such as counting the number of people online every 5 minutes.

        // the current log is        2014-12-20 13:03:12,503 Info number is n        2014-12-20 13:08:12,503 info number is n        2014-12-20 13:13:12,503 INFO number is n         2014-12-20 13:18:12,503 INFO number is n        // Restart server:        2014-12-20 13:27:53,321 INFO number is n         2014-12-20 13:32:53,321 Info number is n        2014-12-20 13:37:53,321 info number is n

Looks a little dizzy.

Solution:
fixed minute execution of tasks, initial increase of a basetime parameter, time calculation dependent basetime to choose to execute or ignore

        2014-12-20 13:00:00,000 Info number is n  //  Current log is        2014-12-20 13:05:00,000 info number is n         2014-12-20 13:10:00,000 Info number is n        2014-12-20 13:15:00,000 info number is n        2014-12-20 13:20:00,000 Info number is n        2014-12-20 13:30:00,000 info number is n  // restart server        2014-12-20 13:35:00,000 Info number is n        2014-12-20 13:40:00,000 info number is n        2014-12-20 13:45:00,000 INFO number is n

So grep out of the log is much more comfortable with time.

Scheduled task Optimization (ii):

--------------------------------------------------------------------------------

15) First to do a point notification function, and then added a timer notification function, suddenly found that this is only a normal task function, and abnormal situation.
For example, we need a remote request to load the data, perhaps this data is relatively important, but as long as the data is available at a time, the problem it may fail.
In other words, I need to go somewhere else to get the data until I get it. Of course now the timer also supports this task, although unfriendly:
Register a per-minute task and remove it if the discovery task is complete.
But the actual problem may be more complex:
If the task execution fails, I will execute it again after 5 seconds;
If I fail again, I will execute it once in 30 seconds;
If it fails again, it will be executed in 3 minutes;
If it fails again, it cannot be carried out indefinitely, or after a certain period of time, there is no point in implementing success.
In their own tasks can handle similar logic, but this is also can be abstract, so need to add a stubborn task, after failure to rest a certain time to execute ;
the number of failures specified (number of attempts) was exhausted and no completion was performed .
Here the need to notify the task executes, the execution function is a return value of success or not.

Summarize

--------------------------------------------------------------------------------

16) Summary
A) The timer notifies "specified tasks that can be performed".
b) Timer "timed" notification "specified task can be performed"
c) Timer "multiple" notifications "need to perform a successful specified task"
d) Timer solves the server system time problem by the way

"Original" Timer and system time (cont.)