shashank created CAMEL-26289:
--------------------------------
Summary: camel-quartz - with deleteJob=false (also with
pauseJob=true) a trigger paused by a stopped endpoint is never resumed after a
restart with a persistent job store, or when the route is added again
Key: CAMEL-26289
URL: https://issues.apache.org/jira/browse/CAMEL-26289
Project: Camel
Issue Type: Bug
Components: camel-quartz
Reporter: shashank
Assignee: shashank
The quartz consumer pauses its trigger when it stops
({{QuartzEndpoint.onConsumerStop}} -> {{pauseTrigger}}, whatever {{pauseJob}}
is; not with a clustered job store), and the endpoint resumes it when the
consumer starts again. Whether to resume is decided by the endpoint's own
{{jobPaused}} flag (main dc990927b60e, {{QuartzEndpoint.resumeTrigger}} lines
639-649), and {{addJobInScheduler}} keeps a trigger that already exists in the
scheduler as it is when its settings did not change (lines 397-401). With the
default {{deleteJob=true}} the endpoint deletes the trigger when it stops, so
nothing stays paused. With {{deleteJob=false}} (which {{pauseJob=true}}
requires) the trigger stays in the scheduler, paused, and a trigger paused by
an earlier endpoint stays paused:
* with a persistent (JDBC) job store that is not clustered, the routes stop
before the scheduler when the application stops, so the trigger is stored
paused; after the restart the new endpoint finds it, does not know it is
paused, and the route never fires again, without any message;
* in one JVM, a route that is removed and added again (a reload, a route
template removed and added) has a new endpoint and never fires again.
Stopping and starting the same route works, because the same endpoint resumes
the trigger it paused. The module has no test for {{deleteJob=false}} or
{{pauseJob}} across a restart or a route added again.
*Fix*: when {{addJobInScheduler}} finds an existing trigger in state
{{PAUSED}}, the endpoint uses {{deleteJob=false}} and the job store is not
clustered, the endpoint marks the trigger as paused by itself, so its consumer
resumes it when it starts (the endpoint start adds the job before the consumer
starts). The check runs after a possible {{rescheduleJob}}. Endpoints with
{{deleteJob=true}} and clustered job stores are not changed (Camel does not
pause triggers in a clustered store). A trigger that was paused outside Camel
(Quartz API) while the route was not running is now resumed when the route
starts, as it already was when the same route was stopped and started; upgrade
guide entry.
*Tests*: new {{QuartzPauseJobRouteAddedAgainTest}}:
{{pauseJobTriggerFiresAgainWhenTheRouteIsAddedAgain}} and
{{keptTriggerFiresAgainWhenTheRouteIsAddedAgain}} ({{deleteJob=false}} without
{{pauseJob}}) fail on main ({{mock://paused Received message count 0, expected
at least 1}}), {{triggerFiresAgainWhenTheRouteIsStartedAgain}} passes on main
(control). New {{SpringQuartzPersistentStorePauseJobRestartAppTest}} (H2 job
store, as {{SpringQuartzPersistentStoreRestartAppTest}}, one route with
{{pauseJob=true&deleteJob=false}} and one with {{deleteJob=false}}): fails on
main, after the restart {{mock://result Received message count 0, expected at
least 1}}. With the fix camel-quartz has 118 tests, 0 failures.
*How it was found*: a random lifecycle-sequence harness (stop, start, suspend,
resume, remove and add of several quartz routes on one scheduler, checking
after each step that started routes fire and stopped ones do not) shrank a
failure to {{[REMOVE(r), ADD(r)]}} for the route with {{pauseJob=true}}; a
review then found that {{deleteJob=false}} alone fails the same way, and the
persistent-store case follows from the same code.
*Affected*: main, camel-4.22.x, camel-4.18.x and camel-4.14.x (same
{{onConsumerStop}}, {{resumeTrigger}} and {{addJobInScheduler}}; read, not run).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
