allthingssecurity opened a new pull request, #28201: URL: https://github.com/apache/camel/pull/28201
# Description [CAMEL-25809](https://issues.apache.org/jira/browse/CAMEL-25809) Follow-up of CAMEL-25700 (#27985), from its review: with `extendMessageVisibility=true` the `TimeoutExtender` extends a message for the first time at 80% of `visibilityTimeout` counted from the start of `processBatch`, but SQS counts the visibility timeout from the receive. With `maxMessagesPerPoll` greater than 10 a poll sends several `ReceiveMessage` requests concurrently and starts the batch only when the last one returned. With long polling (`waitTimeSeconds`), a request that finds no more messages waits up to `waitTimeSeconds` while the messages of the first request are already counting down. With a gap L between the receive and the start of the batch, the first extension comes between L + 0.3 V and L + 0.8 V after the receive (V = `visibilityTimeout`, depending on the phase of the extender), so it is late once L is more than about 0.2 V. Example: `visibilityTimeout=30`, `waitTimeSeconds=20`, a gap of 20 s: the first extension comes 29 to 44 s after the receive, after the message became visible again for 14 of 15 phases. Another consumer then receives the message while it is still processed. Change (in `Sqs2Consumer`): - `poll()` takes the time before the receive requests are sent and passes it to the extender as the receive time of the messages of the poll (never later than their real receive). The public `processBatch(Queue)` keeps using the current time. - `TimeoutExtender.add` counts the deadline from that time and reports when the message is due before the next scheduled run; `processBatch` then runs the extender at once, on its single-thread executor, so the run does not overlap a scheduled one. - Later extensions are unchanged (deadline counted from the successful extension). What users can notice: with long polling (`waitTimeSeconds`) the messages of a poll are dated from the start of the poll, which can be up to `waitTimeSeconds` before a message arrived (also with the default `maxMessagesPerPoll`, as one receive request waits for the first message). Such a message, and the messages of a batch whose poll waited long for its other receive requests, get their first `ChangeMessageVisibilityBatch` call earlier, when the batch starts, never later than before. Without long polling the deadline only moves by the time the receive request takes. Tests: - New `SqsConsumerExtendMessageVisibilityLongPollTest` with the module's `AmazonSQSClientMock` (no AWS): `maxMessagesPerPoll=20&visibilityTimeout=4&extendMessageVisibility=true`; one receive request of the poll returns the message at once, the other waits 3 s (a long poll on a queue with no more messages); the route holds the message until it was extended. The test asserts that the first `ChangeMessageVisibilityBatch` for the message comes less than 4 s after its receive. Without the change it fails: `Expecting actual: 4995L to be less than: 4000L`. - With the change the camel-aws2-sqs unit tests pass: 78 run, 0 failures, 0 errors, 0 skipped. How it was found: a Z3 model of the extension schedule against the visibility window (extender period `max(1, V/2)` s, deadline registration + 0.8 V, a gap L between the receive and the registration): no counterexample with L = 0, a late first extension once L exceeds about 0.2 V. The test above reproduces it with the consumer. What is not changed: a gap of a whole `visibilityTimeout` or more (for example `concurrentRequestLimit` lower than the number of receive requests, so they run one after the other) still lets a message expire before the batch starts; registering each message at its own receive would need the extender inside the polling task. The rounding of the extender period for a small `visibilityTimeout` is CAMEL-25737. What was not run: the integration tests (they need LocalStack); 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-25809](https://issues.apache.org/jira/browse/CAMEL-25809). # 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-aws2-sqs, including the formatter and import-sort plugins. No option or doc 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]
