[
https://issues.apache.org/jira/browse/CAMEL-24079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096484#comment-18096484
]
Claus Ibsen commented on CAMEL-24079:
-------------------------------------
Fixed via https://github.com/apache/camel/pull/24715 (merged to main for
4.22.0).
> 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
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.22.0
>
>
> 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)
