Closed intech closed 1 year ago
@intech Hey! Thank you for opening this issue.
I was a bit busy with the v7.1 release and I needed some time to think about your suggestion.
So your point is about compensating the scheduler interruption time (down time), that may happen because of a consumer failure or any other reason, to avoid gaps for scheduled tasks that run periodically.
Please confirm or correct me if I am wrong.
@weyoss You got that right!
I believe it is not a good idea to try to compensate messages for missed scheduler ticks. Considering that a consumer is down for several hours or maybe days, once it is online, it would take him a huge amount of time/work to perform the following actions:
Additionally, this would require a complete scheduler logic rewrite.
The way the scheduler is currently implemented is simple: each second a scheduler tick is fired. For each tick, the scheduler pull out from the scheduled messages queue
the list of expired/old messages with regards to the timestamp of the tick. Each message of the list is published and the message is scheduled for the next time if it is schedulable.
I am open for discussion.
Closing as abandoned.
:wave: Hey!
I propose to add an option for the message scheduler, which will support two modes of work with intervals:
Current mode by default. Task runs once per second 1,2,3,restart,9,10 Usage example: we make requests to the API, and it makes no sense to do it more often, for example, because of the rate limits.
Strict mode. The task runs once per second 1,2,3,restart,4,5,6,7,8,9,10 were 4-9 jobs processed without delay. Usage example: we collect data per unit of time and cannot skip the time interval to avoid a gap in the data. We take the data time from the task.
I understand that we could solve the problem another way by polling and processing all unselected intervals at once in the first trigger of the scheduler. But, this complicates the monitoring and debugging of the system. 🤔