Ankur Mhatre
eaa8171966
Three replicas of one application against one PostgreSQL database, proving duplicate @Scheduled execution and then removing it with ShedLock: 24 executions where 8 were due, then 7 for 7 ticks. Also measured: @SchedulerLock without @EnableSchedulerLock does nothing and warns about nothing; spring.task.scheduling.pool.size=1 does not starve a fixedRate job but delays it and fires 35 of 40 executions in a burst; and a node whose clock is 40 seconds fast takes a live lock unless the provider uses usingDbTime().
19 lines
926 B
Plaintext
19 lines
926 B
Plaintext
== spring.task.scheduling.pool.size=4 ==
|
|
|
|
over 8 seconds, three @Scheduled methods on one application
|
|
slow() fixedRate 2000 ms, sleeps 1800 ms : 5 executions
|
|
fast() fixedRate 200 ms : 41 executions
|
|
throwing() fixedRate 300 ms, always throws : 27 executions
|
|
distinct scheduler threads : 4 [scheduling-1, scheduling-2, scheduling-3, scheduling-4]
|
|
|
|
longest gap between two fast() executions : 200 ms (200 ms was the schedule)
|
|
fast() executions that started within 20 ms
|
|
of the previous one (the catch-up burst) : 0
|
|
|
|
throwing() kept its schedule after every failure. Spring wraps a scheduled
|
|
method in TaskUtils.LOG_AND_SUPPRESS_ERROR_HANDLER, so each exception is
|
|
logged by o.s.s.s.TaskUtils$LoggingErrorHandler as "Unexpected error
|
|
occurred in scheduled task" and then discarded. A raw
|
|
ScheduledExecutorService would have cancelled the task at the first one.
|
|
|