The NEXT_FIRE_TIME was set to “10s.” Unfortunately, it took more than 60 seconds and didn’t finish within 10 seconds, so it missed the trigger of “10s” “20s”. At “0s”, it was acquired by QuartzSchedulerThread and passed to ExecuteThread to execute. More specific information about misfire instructions will be given within the tutorial lessons specific to each trigger type.įor example, there is a job that should be triggered with 10-second interval. Let’s consider “0s” as a timestamp. When you start using Quartz in your own projects, you should make yourself familiar with the misfire instructions that are defined on the given trigger types, and explained in their JavaDoc. When the scheduler starts, it searches for any persistent triggers that have misfired, and it then updates each of them based on their individually configured misfire instructions. By default they use a ‘smart policy’ instruction – which has dynamic behavior based on trigger type and configuration. The different trigger types have different misfire instructions available to them. Here is the explanation from Quartz‘s official website:Ī misfire occurs if a persistent trigger “misses” its firing time because of the scheduler being shutdown, or because there are no available threads in Quartz’s thread pool for executing the job. Database session increased, and many sessions are wait on “SELECT * FROM qrtz_LOCKS WHERE SCHED_NAME = ‘ ‘ AND LOCK_NAME = ‘TRIGGER_ACCESS’ FOR UPDATE”.īefore we can understand why this happens, let’s learn about misfire.Tons of “Handling the first 20 triggers that missed their scheduled fire-time …” logs in the log file.TIMES_TRIGGERED means how many times it has been triggered. The simple triggers should have the REPEAT_INTERVAL set, which means they are repeat jobs. A lot of jobs in the table simple_triggers wait for execution, but a few in fired_triggers. ![]()
0 Comments
Leave a Reply. |