allthingssecurity opened a new pull request, #27986: URL: https://github.com/apache/camel/pull/27986
# Description [CAMEL-25701](https://issues.apache.org/jira/browse/CAMEL-25701) Since CAMEL-23937 the Service Bus consumer renews message locks itself in `PEEK_LOCK` mode (the default, with the default `maxAutoLockRenewDuration` of 5 minutes, sessions disabled), because the SDK stops renewing when Camel's callback returns, which is immediately for an asynchronous route. The `LockRenewer` is scheduled with `PeriodTaskScheduler.schedulePeriodTask(lockRenewer, 10000)` and renewed a lock when it expired within `LOCK_RENEW_INTERVAL_SECONDS` (10 seconds). The period task scheduler ticks once per second and runs the task when more than 10000 ms have passed since its last run, so two runs are 10 or 11 seconds apart, while the window in which the renewer acted was 10 seconds long. A lock that expired between 10 and 11 seconds after a run was left alone by that run, and the next run came after the expiry, or too close to it for the renewal call. The renewal then failed with a lost lock ("Failed to renew lock" WARN, entry dropped), Service Bus delivered the message again while the first exchange was still being processed, and the final `complete()` of that exchange failed. A small exhaustive timing model (every sequence of 6 run gaps of 10 or 11 seconds, lock expiry at every 100 ms phase) loses the lock in 6.0% of the lock periods with the 10-second margin (11% when every gap is 11 seconds) and in none with a margin of two intervals. Change (`ServiceBusConsumer.LockRenewer.run()`, one line plus comment): renew when the lock expires within `2 * LOCK_RENEW_INTERVAL_SECONDS`. Every lock is then renewed by a run that comes at least about 9 seconds before it expires. What users can notice: long-running exchanges of asynchronous routes keep their lock instead of losing it now and then. Locks are renewed somewhat earlier (about once per lock duration, as before; at every run when the lock duration is 20 seconds or less). No option or default changes, so no upgrade guide entry. Tests (in `ServiceBusConsumerTest`, Mockito, no Service Bus, no waits): - `lockRenewerRenewsALockThatWouldExpireBeforeItsNextRun`: the renewer is captured from the scheduler with its period; a message whose lock expires 2 seconds after the earliest possible next run is tracked and the renewer runs once; it must renew. Fails without the change: `Wanted but not invoked: renewalClient.renewMessageLock(message)`. - `lockRenewerDoesNotRenewALockThatOutlastsTheNextRuns`: a lock that expires in 60 seconds is not renewed. Passes without the change too; it guards against renewing too early. - With the change the camel-azure-servicebus unit tests pass: 79 run, 0 failures, 8 skipped (the integration tests that need a Service Bus namespace). What is not changed: - The renewal is still issued without waiting for the previous one; a renewal that takes longer than an interval is not tracked. - Session-enabled consumers still have no Camel-managed renewal (CAMEL-23938). - The renewer of a stopped consumer stays registered (cancelled) in the period task scheduler until the CamelContext stops. What was not run: the integration tests, a real namespace with long-running exchanges. # 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-25701](https://issues.apache.org/jira/browse/CAMEL-25701). # 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-azure-servicebus, including the formatter and import-sort plugins. 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]
