Add support for detecting misfires in StatsRegistry

[vivekkothari]

Add support for detecting misfires in StatsRegistry. Thanks for building support for micrometer out of the box. It would be really great if you can add support for detecting misfires. We can take a misfireToleranceThreshold as a config param and compare the current time - misfireDuration to executionTime to see if its a misfire. If it is, increment a counter.

[vivekkothari]

I can spin up a PR if you think it's useful.

[kagkarlsson]

Hi! What would be the definition of a misfire?

[vivekkothari]

If the execution_time of a schedule is say x, and it was picked by db-scheduler at x + 1 min, then its a misfire. We can have a misfireToleranceThreshold which is say 10 seconds, so if the schedule was picked +- 10 seconds of its execution time, then its not a misfire.

[kagkarlsson]

Ah I understand. Then I think it would be a misfire if (pickedTime - executionTime) - pollingInterval > misfireToleranceThreshold as the Scheduler currently works. It does not currently peek ahead to know when the next execution will be available for running

[kagkarlsson]

PRs are welcome :)

[vivekkothari]

Oh. Are there plans to look ahead for selecting upcoming schedules?

[kagkarlsson]

It is something I have thought of, but not implemented. Should be fairly easy. After polling for new executions, run an additional query to see when the next execution is due. If sooner than polling-interval, only sleep for that time

[kagkarlsson]

All scheduler-instances will compete for it though, but no big deal I think.