Claus Ibsen created CAMEL-24079:
-----------------------------------
Summary: camel-quartz - QuartzScheduledPollConsumerScheduler may
ignore startScheduler=false
Key: CAMEL-24079
URL: https://issues.apache.org/jira/browse/CAMEL-24079
Project: Camel
Issue Type: Bug
Components: camel-quartz
Affects Versions: 4.21.0
Reporter: Claus Ibsen
Follow-up from CAMEL-24066.
{{QuartzScheduledPollConsumerScheduler}} has the same structural pattern as the
Spring scheduler that was fixed in CAMEL-24066: it schedules the job inside
{{doStart()}} (line 249: {{quartzScheduler.scheduleJob(job, trigger)}}) and
implements {{startScheduler()}} as a no-op (line 102-104: {{// the quartz
component starts the scheduler}}).
This violates the {{ScheduledPollConsumerScheduler}} SPI contract, which
expects {{doStart()}} to only prepare resources and {{startScheduler()}} to
begin actual scheduling.
The impact is partially mitigated because the {{QuartzComponent}} controls when
the Quartz scheduler engine itself starts firing. If the Quartz scheduler is
not yet started when the consumer calls {{doStart()}}, the registered job will
not fire until {{QuartzComponent}} starts the scheduler. However, if the Quartz
scheduler is already running (e.g. other routes already started it), the job
will fire immediately regardless of the {{startScheduler=false}} setting.
Components that rely on {{startScheduler=false}} (file, FTP, SFTP, SMB
consumers and {{GenericFilePollingConsumer}}) could be affected when combined
with {{scheduler=quartz}}.
Suggested fix: align with {{DefaultScheduledPollConsumerScheduler}} by moving
{{quartzScheduler.scheduleJob(job, trigger)}} from {{doStart()}} to
{{startScheduler()}} with an idempotent guard. Care is needed because the
Quartz scheduler lifecycle is more complex (job persistence, clustering,
existing triggers).
_Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
