I am running Advanced Python Scheduler on a server-side daemon process that has two interval jobs configured:
scheduler = BlockingScheduler()
scheduler.add_job(live_cycle, 'interval', seconds=self.tick_size.to_timedelta.total_seconds(), start_time=start_time + self.tick_offset)
scheduler.add_job(live_positions, 'interval', seconds=self.stats_refresh_frequency.to_timedelta.total_seconds(), start_time=start_time)
scheduler.start()
I am using a BlockingScheduler and single-threaded execution mode, as my use case demands quite deterministic execution. Tasks themselves are have short lifetime, should never overlap and nothing bad happens if they are delayed a bit.
My question is about the devops part of BlockingScheduler: there can be long delays before the next scheduled wake up for a job, like weeks. To make sure that the operator of this application has better understanding when to expect more log output, I would like to print out an info level logging statement along the lines:
Scheduler is now going to sleep. Next wake up is in X days Y hours, at 2022-XX-ZZ.
What would be a good way to add this functionality to my app? Should I extend BlockingScheduler or are there any event handler I can use?
Related
I'm using Celery with Django over Redis.
Some of my tasks are quite long, taking about 1 hour. I'm aware that this is suboptimal, and preferably I should use shorter tasks, but this is what I got...
Sometimes the task/worker crash. This can happen for various unimportant reasons. Maybe this worker crashed, network problem, spot-instance when preempted, killed by OOM, or any other unexpected reason that I can't "catch" and handle.
I want to make sure the task will be tried again as fast as possible.
I can use ack_late, but the problem is that this task has a very long timeout (about 90 minutes), which means that if the task started and the worker crashed after 2 minutes, I will now wait for another 88 minutes until the task will get back to the queue and will start executing again on another worker.
I'm wondering if there exists another solution, that will see the worker "disappeared" and will put the task back in the queue?
You could give task_reject_on_worker_lost a try... It is a tricky one, but have a look...
I have this worker whose runtime greatly varies from 10 seconds to up to an hour. I want to run this worker every five minutes. This is fine as long as the job finishes within five minutes. However, If the job takes longer Iron.io keeps enqueuing the same task over and over and a bunch of tasks of the same type accumulate while the worker is running.
Furthermore, it is crucial that the task may not run concurrently, so max concurrency for this worker is set to one.
So my question is: Is there a way to prevent Iron.io from enqueuing tasks of workers that are still running?
Answering my own question.
According to Iron.io support it is not possible to prevent IronWorker from enqueuing tasks of workers that are still running. For cases like mine it is better to have master workers that do the scheduling, i.e. creating/enqueuing tasks from script via one of the client libraries.
The best option would be to enqueue new task from the worker's code. For example, your task is running for 10 sec - 1 hour and enqueues itself at the end (last line of code). This will prevent the tasks from accumulating while the worker is running.
I have a business critical application which needs to run 24*7. Right now its scheduled using Windows Task Scheduler. The problem with current implementation is whenever the application stops it has to wait for 1 minute to run again.(Since one minute is the minimum time to repeat task in Windows Task Scheduler) So I am building my own task scheduler which will start the process(application) within 5 seconds of terminating the process. How should my task scheduler know if the process has terminated. Do I need to keep polling the process every second to check whether its running or not?
You should write your application as a Windows Service, not a standard application.
Among their other advantages, Windows Services give you the ability to define what happens in the event of a failure (e.g. restart application).
They are also very easy to create in C#.
I need to have a specific process(method) run once a day at a given time and was wondering if this can be done using the timer control.
As has been stated, if your process isn't already running, then use Task Scheduler to handle this for you.
However, if you have some background service or something already running, then use a timer, and have it check the system time. Timers are not necessarily accurate, and after a day's worth of running, I would expect them to be way off.
Set up a timer with an interval of 3000ms or so, and when that interval hits, then check the system time to see if it is time for your method to run.
You should create a program that does that process, then exits.
You should then schedule the program using Windows Task Scheduler.
Would like to know how the scheduler gets called so that it can switch tasks. As in even if its preemptive scheduling or round robin scheduling - the scheduler should come in to picture to do any kind of task switching. Supposing a low priority task has an infinite loop - when does the scheduler intervene and switch to a higher priority task?
Query is:
1. Who calls the scheduler? [in VxWorks]
2. If it gets called at regular intervals - how is that mechanism implemented?
Thanks in advance.
--Ashwin
The simple answer is that vxWorks takes control through a hardware interrupt from the system timer that occurs continually at fixed intervals while the system is running.
Here's more detail:
When vxWorks starts, it configures your hardware to generate a timer interrupt every n milliseconds, where n is often 10 but completely depends on your hardware. The timer interval is generally set up by vxWorks in your Board Support Package (BSP) when it starts.
Every time the timer fires an interrupt, the system starts executing the timer interrupt handler. The timer interrupt handler is part of vxWorks, so now vxWorks has control. The first thing it does is save the CPU state (such as registers) into the Task Control Block (TCB) of the currently running task.
Then eventually vxWorks runs the scheduler to determine who runs next. To run a task, vxWorks copies the state of the task from its TCB into the machine registers, and after it does that the task has control of the CPU.
Bonus info:
vxWorks provides hooks into the task switching logic so you can have a function get called whenever your task gets preempted.
indiv provides a very good answer, but it is only partially accurate.
The actual working of the system is slightly more complex.
The scheduler can be executed as a result of either synchronous or asynchronous operations.
Synchronous refers to operations that are caused as a result of the code in the currently executing task. A prime example of this would be to take a semaphore (semTake).
If the semaphore is not available, the currently executing task will pend and no longer be available to execute. At this point, the scheduler will be invoked and determine the next task that should execute and will perform a context switch.
Asynchronous operations essentially refer to interrupts. Timer interrupts were very well described by indiv. However, a number of different elements could cause an interrupt to execute: network traffic, sensor, serial data, etc...
It is also good to remember that the timer interrupt does not necessarily cause a context switch! Yes, the interrupt will occur, and delayed task and the time slice counters will be decremented. However, if the time slice is not expired, or no higher priority task transitions from the pended to the ready state, then the scheduler will not actually be invoked, and you will return back to the original task, at the exact point where execution was interrupted.
Note that the scheduler does not have its own context; it is not a task. It is simply code that executes in whatever context it is invoked from. Either from the interrupt context (asynchronous) or from the invoking task context (synchronous).
Unless you have a majorily-customized target build, the scheduler is invoked by the Timer interrupt. Details are platform-specific, though.
The scheduler also gets invoked if current task gets completed or blocks.