allthingssecurity opened a new pull request, #28642: URL: https://github.com/apache/camel/pull/28642
# Description [CAMEL-26289](https://issues.apache.org/jira/browse/CAMEL-26289) 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 was decided by the endpoint's own `jobPaused` flag, and `addJobInScheduler` keeps a trigger that already exists in the scheduler as it is when its settings did not change. With the default `deleteJob=true` the endpoint deletes the trigger when it stops. With `deleteJob=false` (which `pauseJob=true` requires) the trigger stays, paused, so a trigger paused by an earlier endpoint stayed 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 that 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) gets a new endpoint and never fires again. Stopping and starting the same route works, because the same endpoint resumes the trigger it paused. Changes: - `QuartzEndpoint.addJobInScheduler`: when the trigger already exists and is `PAUSED`, the endpoint uses `deleteJob=false` and the job store is not clustered, the endpoint marks it as paused (`jobPaused`), as if it had paused it itself, so `onConsumerStart` resumes it (the endpoint start adds the job before the consumer starts). The check runs after a possible `rescheduleJob`. - Endpoints with `deleteJob=true` are not changed. A clustered job store is not changed either: Camel never pauses its triggers (`pauseTrigger` returns for a clustered store), so a paused trigger there was paused by someone else. - A trigger that was paused outside Camel (for example with the Quartz API) while the route was not running is now resumed when the route starts. Camel already resumed it when the same route was stopped and started (its stop marks the trigger as paused by itself). - Upgrade guide 4.24: `camel-quartz - a route that keeps its trigger fires again when it is added again or after a restart`. No option or generated file change. - Backport: camel-4.22.x, 4.18.x and 4.14.x have the same `onConsumerStop`, `resumeTrigger` and `addJobInScheduler` (read, not run). The upgrade note is about the trigger paused outside Camel; I would keep it on main unless you prefer otherwise. Tests: - New `QuartzPauseJobRouteAddedAgainTest` (`BaseQuartzTest`, `MockEndpoint`), two routes, one with `pauseJob=true&deleteJob=false` and one with `deleteJob=false`: - `pauseJobTriggerFiresAgainWhenTheRouteIsAddedAgain` and `keptTriggerFiresAgainWhenTheRouteIsAddedAgain` fail on main: `mock://paused Received message count 0, expected at least 1` (and `mock://kept`). - `triggerFiresAgainWhenTheRouteIsStartedAgain` passes on main and with the change; it is the control. - New `SpringQuartzPersistentStorePauseJobRestartAppTest` with two Spring XML files, copies of the ones of `SpringQuartzPersistentStoreRestartAppTest` (H2 job store) with the same two routes: fails on main, after the restart `mock://result Received message count 0, expected at least 1` (the surefire reruns of it then fail on the H2 tables the first run created, as they would for the existing restart test). - camel-quartz: 118 tests, 0 failures. The formatter and import-sort plugins ran. 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 every step that started routes fire and stopped ones do not) shrank a failure to removing and adding 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. Not tested: a clustered job store (the code path there is unchanged). # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL-26289) filed for the change (usually before you start working on it): [CAMEL-26289](https://issues.apache.org/jira/browse/CAMEL-26289). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built camel-quartz and ran its tests, including the formatter and import-sort plugins. No generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
