I was told to use crontab expression to make my schedule trigger run every 3 minutes, however, I notice that it's not actually running every 5 minutes, what its doing is it runs a process for a period of 3 minutes and then it stops even if the process is not complete.
I need the trigger to run every 3 minutes but if its in the middle of a process then to complete the current process. Can you advise, please?
I noticed in the schedule trigger you have “start instance” and “stop instance”, currently they are both false. My guess is I need to do something with these?
The triggers never interrupt the script execution.
The special variable timeout is what will solve your problem. According to the manual the timeout special variable:
Defines the maximal robot process duration time (in milliseconds), after which the process terminates; the default value is 180000 (3 minutes).
Which means that a script will stop after 3 minutes if its timeout's variable value stays default.
Add the below line of code at the beginning of your script to prevent this from happening after 3 minutes and increase its maximal robot process duration time.
♥timeout = 1800000
By the way if you have set up your triggers to launch a script every 3 minutes and the script's duration time is for example 4 minutes, the script will be launched the next time automatically after because it is 1 minute late and it creates a queue of scripts to be executed.
Related
I need to start a job every 30 minutes, but before a new job is being started I want the old but same job being terminated. This is to make sure the job always fetches the newest data file which is constantly being updated.
Right now I'm using the BlockingScheduler paired with my own condition to stop the job (stop job if processed 1k data etc.), I was wondering if APScheduler supports this "only 1 job at the same time and stop old one before new one" behavior natively
I've read the docs but I think the closest is still the default behavior which equals max_instances=1, this just prevents new jobs firing before the old job finishes, which is not what I'm looking for.
Any help is appreciated. Thanks!
After further research I came to a conclusion that this is not supported natively in APScheduler, but by inspired by
Get number of active instances for BackgroundScheduler jobs
, I modified the answer into a working way of detecting the number of current running instances of the same job, so when you have a infinite loop/long task executing, and you want the new instance to replace the old instance, you can add something like
if(scheduler._executors['default']._instances['set_an_id_you_like'] > 1):
# if multiple instances break loop/return
return
and this is what should look like when you start:
scheduler = BlockingScheduler(timezone='Asia/Taipei')
scheduler.add_job(main,'cron', minute='*/30', max_instances=3, next_run_time=datetime.now(),\
id='set_an_id_you_like')
scheduler.start()
but like the answer in the link, please refrain from doing this if someday there's a native way to do this, currently I'm using APScheduler 3.10
This method at least doesn't rely on calculating time.now() or datetime.datetime.now() in every iteration to check if the time has passed compared when the loop started. In my case since my job runs every 30 minutes, I didn't want to calculate deltatime so this is what I went for, hope this hacky method helped someone that googled for a few days to come here.
What is the purpose of setting the loop count? Is it just depend on how many times i want to run the test? Or it has other purpose of test with different loop count? Will it affect the final test result?
"If you give loop count as 2 then every request two times to the server"
I found this online, but i don't understand what it means.
Based on my understanding, the loop count set to 2 because of i want to repeat the test twice only. After the first test end, then the threads in first round test in dead before the second test starts. Then the new thread group will send the request to the server. Why "every request two times to the server"?
The loop count means each thread of your thread group will run the steps inside the loop twice if iteration is set to 2
The thread will start based on delay and rampup and not related to this setting
If your server has concurrent users limit, for example 100, and you want to execute more, as 600, you can set loop count as 6 and execute 600 requests with given server limits
It's the number of times for each JMeter thread (virtual user) to execute Samplers inside the Thread Group
Each JMeter thread executes Samplers upside down (or according to the Logic Controllers) so if there are no more Samplers to execute the thread will shut down. And it might be the case you won't be able to achieve the desired concurrency because some threads have already finished execution and some haven't been yet started like it's described in the JMeter Test Results: Why the Actual Users Number is Lower than Expected so you might want to increase the number of iterations or even set it to "Infinite" and control the test duration using "Duration" section of the Thread Group or Runtime Controller
I have repetitive tasks that I want to process with a number of workers (i.e., competing consumers pattern). The probability of failure during the task is fairly low so in case of such rare events, I would like to try again after a short period of time, say 1 second.
A sequence of consecutive failures is even less probable but still possible, so for a few initial retries, I would like to stick to a 1-second delay.
However, if the sequence of failures reaches some point, then the most likely there is some external reason that may cause these failures. So from that point, I would like to start extending the delay.
Let's say that the desired distribution of delays looks like this:
first appearance in the queue - no delay
retry 1 - 1 second
retry 2 - 1 second
retry 3 - 1 second
retry 4 - 5 second
retry 5 - 10 seconds
retry 6 - 20 seconds
retry 7 - 40 seconds
retry 8 - 80 seconds
retry 9 - 160 seconds
retry 10 - 320 seconds
another retry - drop the message
I have found a lot of information about DLXes (Dead Letter Exchanges) that can partially solve the problem. It appears to be easy to achieve an infinite number of retries with the same delay. At the same time, I haven't found a way to increase the delay or to stop after certain number of retries.
I'm looking for the purest RabbitMQ solution possible. However, I'm interested in anything that works.
There is a plugin available for this. I think you can use it to achieve what you need.
I've used it for something in a similar fashion for handling custom retries with dynamic delays.
RabbitMQ Delayed Message Plugin
Using a combination of DLXes and expire/TTL times, you can accomplish this except for the case when you want to change the redelivery time, for instance, implementing an exponential backoff.
The only way I could make it work using a pure RabbitMQ approach is to set the expire time to the smallest time needed and then use the x-death array to figure out how many times the message has been killed and then reject (ie. DLX it again) or ack the message accordingly.
Let's say you set expire time to 1 minute and you need to backoff 1 minute first time, then 5 minutes and then 30 minutes. This translates to x-death.count = 1, followed by 5 and then 30. Any other time you just reject the message.
Note that this can create lots of churn if you have many retry-messages. But if retries are rare, go for it.
How accurate are the start-/stop-timestamps in batch-history?
I've noticed, that a batch runtime is declared with one minute in the history. The code executed by the batch includes a find-method and only if this returns false, further code is executed. The find-method itself runs nearly instantly.
I've added timestamps in code via info-logs and can see those in the history of the batch. one timestamp is at the very first line and another one at the very last line of code. the delta is 0.
So I'm asking, from what this time-delta (stop-start of history against timestamps in code) comes from?!
Is there any "overhead" or sth. which takes an amount of time everytime a batch is executed?
The timestamps in BatchJobHistory (Batch job history) are off by up to a minute.
The timestamps in BatchHistory (Show tasks) are pretty accurate (one second resolution).
The timestamps in BatchJobHistory represents when the batch was started and observed finished by the batch system. Due to implementation details this may differ by 60 seconds from the real execution times recorded in BatchHistory.
This is yet another reason why it is difficult to monitor the AX batch system.
If you have round robin enabled in Vxworks and your task gets preempted by a higher priority task, what happens to the remaining time slice?
Your task will resume execution and finish the remainder of the time slice.
Note that you will have some jitter that occurs for one time tick, since time slicing has a granularity of 1 clock tick.
For example:
You have round robin enabled with a 10 clock tick time slice. One clock tick is 10 ms. You expect 100 ms per time slice.
You get pre-empted at 5 ms (the middle of your 1st tick). You should run for 95ms more, but VxWorks considers that you still have 10 ticks to go.
If the task gets the cpu back at 11ms, you will execute 99ms more.
If the task gets the cpu back at 19ms, you will execute 91ms more.
Every time you get pre-empted, your task might execute +/- 1 tick in absolute time.