I have a process in which I have used a timer event. The timer event is of type
Duration and has wait time of 30 minutes(PT30M). This timer event is expected to end exactly after 30 minutes, but it takes additional 15 or 30 seconds.
This behavior is observed and the delay is exactly 15 or 30 seconds every time even if I change (increase or decrease) the duration of timer event. I would like to know why does it take 15 seconds extra then required to execute.
A timer in a BPMN process is persisted as a job in Camunda. The job executor component repeatedly polls the job table for any jobs that are due. In case there are no due jobs, the polling applies exponential backoff, by default sleeping up to 60 seconds between polling attempts. So if your system has little load, this kind of delay is to be expected. You can use the job executor configuration property maxWait to change the maximum sleeping period.
Relevant documentation:
Job executor in general: https://docs.camunda.org/manual/7.10/user-guide/process-engine/the-job-executor/#job-executor-activation
Job executor configuration properties: https://docs.camunda.org/manual/7.10/reference/deployment-descriptors/tags/job-executor/
Related
I have a problem when the scheduled starts, it has a subsequent process that lasts longer than each interval, that is, every 2 seconds it starts the process, but if it takes 4 seconds to finish, my problem is that I don't know how to prevent the interval from starting. until the last task is completed.
I'd appreciate any help.
Set the max concurrency attribute of the flow to 1.
When I run a job with Kitchen.bat, the job takes 100 seconds to start and I find the following line in the logs:
ERROR [KarafLifecycleListener] The Kettle Karaf Lifecycle Listener failed to execute properly after waiting for 100 seconds. Releasing lifecycle hold, but some services may be unavailable.
Is there a way to speed up the job start-up time?
Thanks
The question is:
How should I configure the Watchdog Timer if I have 3 tasks with different priorities and different execution time?
Say:
Task1: Highest Priority , Exec. Time = 5 ms
Task2: Medium Priority , Exec. Time = 10 ms
Task3: Lowest Priority , Exec. Time = 15 ms
The proper way to do this is
Create a special watchdog task that waits on 3 semaphores/mutexes/message queues (sequentially) in a loop
Feed those three semaphores from your worker tasks (each task feeds one semaphore of the watchdog task)
re-set the watchdog timer in the watchdog task's loop to the sum of the loop timing of all worker tasks (worst case) plus some headroom.
If any of your worker tasks or the watchdog tasks hangs, it will eventually block the watchdog task and the watchdog will expire. You want to make sure the watchdog is only re-triggered when all tasks are running properly. Use the simplest inter-task communication means your RTOS provides to make it as robust as possible against crashes.
Look at this definition
A watchdog timer is an electronic timer that is used to detect and recover from computer malfunctions. During normal operation, the computer regularly resets the watchdog timer to prevent it from elapsing, or "timing out"
So you set the watchdog timer value, that trigger watchdog when you are sure none of 3 tasks is running. To be more accurate, you reset the timer when you are sure all of the tasks are running. When a single task stopped due to unknown reason, you want to trigger watchdog (you can read more on it)
Now the real thing, what should be time for watchdog timer? you need to set a timer when you want to restart the program, so include all wait time for a task, delays in tasks and check worst-case time (max time) for all tasks to be executed at least once. then set the timer value a little bit more than this max value.
Microsoft's documentation states:
Background tasks are meant to be short-lived tasks that do not consume a lot of resources.
It also says:
Each app on the lock screen receives 2 seconds of CPU time every 15 minutes, which can be used by all of the background tasks of the app. At the end of 15 minutes, each app on the lock screen receives another 2 seconds of CPU time for use by its background tasks.
I need to run a background task every two minutes to update my live-tile.
My app is a lock-screen-app.
Computation is within the CPU and network usage constraints
Can I create a permanent background task (e.g. something which polls a web service and pulls information, waits and loops) to create a OneShot TimeTrigger every two minutes or is there a better way of doing this?
My concern with the background task option is whether the runtime would deem the task inactive while it was sleeping and close it or something else like there's a limit on the number of times a live tile can be updated within 15 minutes...
Yes, if by long lived you mean under 25 minutes.
Time triggers cannot execute more frequent than 15 minutes. Creating a OneShot trigger that executes in 2 minutes is, that's an interesting idea and should work. Yes, background tasks can register other background tasks to keep this chain going. Should the user's machine be off when it execs it will queue later.
Having said that, updating your tile that frequently & using a background task is not a wise solution. Because, it is unreliable. Background tasks can be disabled, for one. But every 15 minutes, you are going to exceed your quota. Try using a Scheduled tile instead.
If I have an event that starts a timer with an interval of say, 30 minutes, and 15 minutes later, the computer the app is running on sleeps (Suspend to RAM) or Hibernates (Suspend to Disk), and is brought back online after ten minutes, will the timer raise its Tick event in 5 minutes (30 minutes REAL time from the start) or 15 minutes (30 minutes RUNTIME from the start)?
The timer maintains whatever state it was in before hibernation or suspension. When the system resumes from hibernate/restore, it will resume from where it was before. In other words, the timer will not run while the system is asleep.