l*****b
发帖数: 82 | 1 I have a TimerTask to trigger the transaction at every hours (e.g. 1:00, 2:
00, 3:00, etc). As to the instruction of method TimerTask.
scheduledExecutionTime(), I have the following codes to skip some overdue
tasks:
public void run() {
if (System.currentTimeMillis() - scheduledExecutionTime() >= 1000)
return; // 1 s delay, Too late; skip this execution.
// Perform the task
}
But I encounter some strange issue which this code works in one of my server
box but rather than the other server box (whi | A**o
发帖数: 1550 | 2 my guess is when your server is idle, everything was swapped to disk by the
system. then 1s delay is not abnormal. maybe you want to have 5min preload
event to make sure your jboss is active and in the memory?
and your workaround works. that's all it matters. | F****n
发帖数: 3271 | 3 It's has nothing to do with System.currentTimeMillis(). More likely, it is
because of your Timer. Check the Timer you are using. For example, are you using fixed-delay or fixed-rate scheduling? java.util.Timer.schedule is fixed-delay by default, so it will count ONLY AFTER the last execution completes. | b******y
发帖数: 9224 | 4
using fixed-delay or fixed-rate scheduling? java.util.Timer.schedule is
fixed-delay by default, so it will count ONLY AFTER the last execution
completes.
Wow, makes sense.
【在 F****n 的大作中提到】
: It's has nothing to do with System.currentTimeMillis(). More likely, it is
: because of your Timer. Check the Timer you are using. For example, are you using fixed-delay or fixed-rate scheduling? java.util.Timer.schedule is fixed-delay by default, so it will count ONLY AFTER the last execution completes.
| g*****g
发帖数: 34805 | 5 Use quartz, it's more powerful than java timer.
server
【在 l*****b 的大作中提到】
: I have a TimerTask to trigger the transaction at every hours (e.g. 1:00, 2:
: 00, 3:00, etc). As to the instruction of method TimerTask.
: scheduledExecutionTime(), I have the following codes to skip some overdue
: tasks:
: public void run() {
: if (System.currentTimeMillis() - scheduledExecutionTime() >= 1000)
: return; // 1 s delay, Too late; skip this execution.
: // Perform the task
: }
: But I encounter some strange issue which this code works in one of my server
| b******y
发帖数: 9224 | 6 I still like the Linux cron. | l*****b
发帖数: 82 | 7
using fixed-delay or fixed-rate scheduling? java.util.Timer.schedule is
fixed-delay by default, so it will count ONLY AFTER the last execution
completes.
Thanks, Foxman. I use fixed-rate scheduling as the following method:
public void scheduleAtFixedRate(TimerTask task, Date firstTime, long period)
Tasks are triggered at every hour per day.
I found the difference of System.currentTimeMillis() and
scheduledExecutionTime() increased gradually by 500ms and stops at about
12000ms and keep stable. I
【在 F****n 的大作中提到】
: It's has nothing to do with System.currentTimeMillis(). More likely, it is
: because of your Timer. Check the Timer you are using. For example, are you using fixed-delay or fixed-rate scheduling? java.util.Timer.schedule is fixed-delay by default, so it will count ONLY AFTER the last execution completes.
| m******t
发帖数: 2416 | 8
Heh, nothing beats cron indeed.
That said, if your deployment environment isn't entirely under
your control, it often becomes a political struggle with another
team over cronjobs.
【在 b******y 的大作中提到】
: I still like the Linux cron.
|
|
