Camel 3.13 (but I also tried 3.6 and results are worse)
I have an issue where a quartz route is misfiring at the beginning of the
startup. I ran some standalone Quartz scheduler with a simple job and
trigger and it works as expected, even with a small interval (<200ms).
In the case of Camel, the interval is not being respected in the first few
exchanges.
Notice at the end of the log how the first QUARTZ log entries are piled
together (interval 1200). If I shorten the interval I can pile them up even
more (3 entries in 100ms with interval 200ms)
...:46,750 INFO [main ] o.a.c.t.j.CamelTestSupport -
********************************************************************************
...:46,753 INFO [main ] o.a.c.t.j.CamelTestSupport - Testing: a()
(BlahTest)
...:46,755 INFO [main ] o.a.c.t.j.CamelTestSupport -
********************************************************************************
...:46,915 INFO [main ] .s.o.s.BlahTest$bootstrapper$1 - Run event
handler 1/1 for BEFORE_CONF
...:47,252 INFO [main ] o.a.c.i.e.AbstractCamelContext - MDC logging is
enabled on CamelContext: camel-1
...:47,253 INFO [main ] o.a.c.c.quartz.QuartzComponent - Create and
initializing scheduler.
...:47,254 INFO [main ] o.a.c.c.quartz.QuartzComponent - Setting
org.quartz.scheduler.jmx.export=true to ensure QuartzScheduler(s) will be
enlisted in JMX.
...:47,314 INFO [main ] o.q.impl.StdSchedulerFactory - Using default
implementation for ThreadExecutor
...:47,318 INFO [main ] o.q.simpl.SimpleThreadPool - Job execution
threads will use class loader of thread: main
...:47,332 INFO [main ] o.q.core.SchedulerSignalerImpl - Initialized
Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
...:47,333 INFO [main ] o.quartz.core.QuartzScheduler - Quartz
Scheduler v.2.3.2 created.
...:47,334 INFO [main ] org.quartz.simpl.RAMJobStore - RAMJobStore
initialized.
...:47,514 INFO [main ] o.quartz.core.QuartzScheduler - Scheduler
meta-data: Quartz Scheduler (v2.3.2) 'DefaultQuartzScheduler-camel-1' with
instanceId 'NON_CLUSTERED'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support
persistence. and is not clustered.
...:47,514 INFO [main ] o.q.impl.StdSchedulerFactory - Quartz
scheduler 'DefaultQuartzScheduler-camel-1' initialized from an externally
provided properties instance.
...:47,514 INFO [main ] o.q.impl.StdSchedulerFactory - Quartz
scheduler version: 2.3.2
...:47,545 INFO [main ] o.a.c.c.quartz.QuartzEndpoint - Job
Camel_camel-1.resolver (triggerType=SimpleTriggerImpl,
jobClass=StatefulCamelJob) is scheduled. Next fire date is Thu Dec 16
19:54:47 WET 2021
...:47,977 INFO [main ] o.a.c.i.e.AbstractCamelContext - Routes startup
summary (total:2 started:2)
...:47,977 INFO [main ] o.a.c.i.e.AbstractCamelContext - Started
quartz-daemon (quartz://resolver)
...:47,977 INFO [main ] o.a.c.i.e.AbstractCamelContext - Started
route1 (seda://out)
...:47,977 INFO [main ] o.a.c.i.e.AbstractCamelContext - Apache Camel
3.13.0 (camel-1) started in 1s26ms (build:96ms init:205ms start:725ms)
...:47,979 INFO [main ] o.a.c.c.quartz.QuartzComponent - Starting
scheduler.
...:47,980 INFO [main ] o.quartz.core.QuartzScheduler - Scheduler
DefaultQuartzScheduler-camel-1_$_NON_CLUSTERED started.
...:47,993 INFO [main ] o.a.c.c.mock.MockEndpoint - Asserting:
mock://end is satisfied
...:48,027 INFO [Worker-1] quartz-daemon - QUARTZ
...:48,722 INFO [Worker-2] quartz-daemon - QUARTZ
...:49,923 INFO [Worker-3] quartz-daemon - QUARTZ
...:51,122 INFO [Worker-4] quartz-daemon - QUARTZ
...:52,321 INFO [Worker-5] quartz-daemon - QUARTZ
...:53,523 INFO [Worker-6] quartz-daemon - QUARTZ
...:54,526 INFO [main ] o.a.c.c.mock.MockEndpoint - Re-asserting:
mock://end is satisfied after 1000 millis
The route I am using is incredibly simple
from("quartz:resolver?trigger.repeatInterval=1200&stateful=true&triggerStartDelay=0")
.id("quartz-daemon")
.log("QUARTZ")
.process(processorName) // trivial, creates arrays with 2-3
random Int
.marshal()
.json(JsonLibrary.Jackson)
.to("mock:end")
Am I missing some specific Camel-Quartz configuration that would cause
these misfires?
I would like the scheduler to respect the interval, is this a Quartz issue?
Am I missing some specific misfire configuration that deals with these
cases?
