allthingssecurity opened a new pull request, #28321: URL: https://github.com/apache/camel/pull/28321
# Description [CAMEL-25848](https://issues.apache.org/jira/browse/CAMEL-25848) `CronScheduledRoutePolicy` and `SimpleScheduledRoutePolicy` suspend the consumer of the route with `suspendOrStopConsumer`, which stops a consumer that is not `Suspendable` (netty, mina, mllp, paho, paho-mqtt5, grpc, azure-servicebus, google-pubsub and others). The route stays `Started`. The scheduled resume only resumed a suspended consumer and logged "The Consumer ... is not suspended and cannot be resumed" for a stopped one, and the scheduled start of a `Started` route did nothing. So such a consumer stayed stopped after the first scheduled suspend, until the route was restarted: a nightly suspend/resume window on a netty or MLLP listener left the port closed for good. Change (`ScheduledRoutePolicy.onJobExecute`): a scheduled resume, and a scheduled start of a `Started` route, call `resumeOrStartConsumer` when the consumer is suspended, or when the scheduled suspend of the policy stopped it (the policy records that per route, and forgets it when the consumer or the route starts again or the route stops). `resumeOrStartConsumer` already starts a consumer that is not `Suspendable`, as the throttling route policies use it. A stopped route is still started with `startRoute`, and a running consumer still gets the WARN on resume. Not while the route or Camel stops: the shutdown strategy stops (or suspends) the consumer of a started route, then waits for the in-flight exchanges (up to 45 s by default) while the route status stays `Started`, and only then stops the route. A trigger that fires in between must not start the consumer again. So a stopped consumer is only started when the policy's own suspend stopped it, not when the shutdown strategy (or another policy) did; and the policy checks `isResumeOrStartConsumerAllowed(route)` first, as the throttling route policies do since CAMEL-25018, which covers the context shutdown. On main the same window already exists for a `Suspendable` consumer (the shutdown suspends it, and a scheduled resume resumes it); that is unchanged here. What users can notice: the consumer comes back at the scheduled resume (or start) time, as the policy page describes. No option changed, so no upgrade guide entry. Tests: - New `ScheduledRoutePolicyNonSuspendableConsumerTest` (4 tests) with a test endpoint whose consumer is a plain `DefaultConsumer`. `scheduledResumeStartsConsumerThatWasStoppedBySuspend` uses a `SimpleScheduledRoutePolicy` with real Quartz triggers; without the change it fails with `consumer should be started again ==> expected: <true> but was: <false> within 5 seconds`. `scheduledStartStartsConsumerThatWasStoppedBySuspend` runs the SUSPEND and START actions of a `CronScheduledRoutePolicy`; without the change it fails with `expected: <true> but was: <false>`. Both pass with the change. - `scheduledResumeOrStartDoesNotStartTheConsumerWhileCamelStops` (same class): a `DefaultShutdownStrategy` subclass runs the RESUME and START actions right after the shutdown stopped the consumer; the consumer must stay stopped. Without the `isResumeOrStartConsumerAllowed` check it fails with `the consumer was started again while Camel stopped ==> expected: <[]> but was: <[RESUME, START]>`. - `scheduledResumeOrStartDoesNotStartTheConsumerWhileTheRouteStops`: the same with `stopRoute` instead of `context.stop()` (found in review: the route status stays `Started` while the shutdown strategy waits, so the `isResumeOrStartConsumerAllowed` check does not cover it). If any stopped consumer is started, it fails with `the consumer was started again while the route stopped ==> expected: <[]> but was: <[RESUME, START]>`; it passes with the per-route record of the suspend. - With the change the unit tests of camel-quartz pass: 112 run, 0 failures. What was not run: a netty or MLLP route with the policy, the full root build. # 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) filed for the change (usually before you start working on it): [CAMEL-25848](https://issues.apache.org/jira/browse/CAMEL-25848). # 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 and tested camel-quartz. No option and no component page changed. 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]
