Hello,
Looks like an effect of misfire instruction.
Point 2: if there was a firing moment during the pause - it’s definitely a misfire.
Point 1: it’s not clear about the second part - “changes in campaign scheduled” - but it still looks like Quartz engine treat it as a misfire.
Triggers created from Jmix UI are built with default misfire instruction - ‘Smart policy’ - it depends on trigger implementation. In case of cron-trigger it’s a ‘execute once ASAP’.
Created ticket to support misfire configuration - Quartz: support misfire instruction configuration in UI · Issue #2160 · jmix-framework/jmix · GitHub.
As a WA, if your trigger can be ‘static’ (defined in compile time) you can declare job via Quartz API.
Example:
- Create Configuration class and define there JobDetails and Trigger beans.
- Setup proper misfire instruction via CronScheduleBuilder within Trigger creation.
@Configuration
public class PredefinedJobConfiguration {
@Bean("predefinedTestJob")
JobDetail predefinedTestJob() {
return JobBuilder.newJob()
.ofType(TestJob.class)
.storeDurably()
.withIdentity("PredefinedTestJob")
.build();
}
@Bean("predefinedTestJobTrigger")
Trigger predefinedTestJobTrigger(@Qualifier("predefinedTestJob") JobDetail job) {
return TriggerBuilder.newTrigger()
.withIdentity("PredefinedTestJobTrigger")
.forJob(job)
.startNow()
.withSchedule(CronScheduleBuilder.cronSchedule(
"0 * * * * ?")
.withMisfireHandlingInstructionDoNothing()
)
.build();
}
}