allthingssecurity opened a new pull request, #28434: URL: https://github.com/apache/camel/pull/28434
# Description [CAMEL-25910](https://issues.apache.org/jira/browse/CAMEL-25910) A deterministic simulation test (camel-test-dst) of the camel-kafka-share consumer, in the `dst` package of its tests, in the same form as the SQS, Event Hubs and Slack worlds: `KafkaShareConsumerDstTest` (1000 seeds), `KafkaShareWorld` and `FakeShareGroup`. Test only; no main code changes. What the world models: the real consumer (`KafkaShareConsumer`, `KafkaShareFetchRecords`) and Camel's routing run on the virtual-time loop; only the share group is faked, as a `ShareConsumer` dynamic proxy set through `KafkaShareComponent.setKafkaShareClientFactory`. The fake follows KIP-932 and the `KafkaShareConsumer` Javadoc: acquisition locks that expire, a delivery count and archiving at the delivery limit, explicit acknowledgement (a poll with records not acknowledged, or a second acknowledgement, throws `IllegalStateException` as the client does), acknowledgements sent with the next poll, commit or close, the acknowledgement commit callback called with the acknowledged offsets at the start of a later `poll`, `commitSync` or `commitAsync` (as kafka-clients 4.3.1 `ShareConsumerImpl.handleCompletedAcknowledgements`; not from within `commitAsync`), a stale acknowledgement answered with `InvalidRecordStateException`, `wakeup`, and `close` releasing what was acquired and not ackn owledged. The seed picks `onFailure`, `commitMode`, `pollOnError`, `pollTimeoutMs`, `shutdownTimeout`, the creation backoff, `maxPollRecords`, the lock duration and the delivery limit, and injects share consumer creation, poll, commit and processing failures, processing slower than the lock, route restarts and suspend/resume. An operator starts the route again when its start fails, as the supervising route controller does. Invariants: the share consumer is used as its Javadoc requires; a record is accepted only for a delivery the route completed; every published record completes at least once or is archived by the group; once the faults are cleared the group is drained and the started route holds one share consumer; no share consumer is left open after the route stopped. Limits, written in the world's Javadoc: `consumersCount` is 1 (each consumer thread loops for ever, and on the one stack of the harness a second looping thread nested above the first would never let it resume); processing takes time only after the route operations are done (a route stop above an exchange that blocks in the route would wait for ever); locks do not exclude on the one stack, so a stop never waits for the processing lock. Not modelled: several partitions, the batch_optimized acquire mode, lock renewal, the group's heartbeat and assignment. Other changes: - `camel-test-dst` as a test dependency of camel-kafka-share. - The test log of camel-kafka-share is at WARN in a size-capped rolling file (50 MB), as a failing world can log a lot. - The camel-test-dst page lists the world with the others (and its catalog copy, byte-identical). Its intro no longer counts the worlds ("These worlds ..."), the same line as the camel-pulsar DST world of CAMEL-25869, which adds its own row, so the two merge in either order without a conflict. Tests: - On main: 5000 of 5000 seeds pass (`-Ddst.seeds=5000`). Seed 8 replayed in two JVMs gives the same trace hash. - Self-check: the consumer has no past fix of this behaviour to revert, so two faults were planted in `KafkaShareFetchRecords` locally (not committed). A failed exchange acknowledged with ACCEPT instead of `onFailure`: 1953 of 5000 seeds fail, all with "accepted ... but the route did not complete that delivery". `pollOnError=RECONNECT` ending the consumer thread instead of reconnecting: 385 of 5000 seeds fail, all with `RECONNECT` and poll failures, on "a started route holds one share consumer". - camel-kafka-share unit tests: 1027 run (27, plus 1000 seeds), 0 failures, 0 errors, 0 skipped. camel-test-dst: 49 run, 0 failures. camel-kafka-common: 11 run, 0 failures. - Merged with the open camel-kafka-share fix of CAMEL-25872 (CamelContext suspend/resume), the world passes too (1000 of 1000). What was not run: the ITs (they need Docker); 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-25910](https://issues.apache.org/jira/browse/CAMEL-25910). # 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-test-dst, camel-kafka-common and camel-kafka-share, including the formatter and import-sort plugins. The only generated file touched is the catalog copy of the camel-test-dst page, which is byte-identical to the page. 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]
