allthingssecurity opened a new pull request, #27324: URL: https://github.com/apache/camel/pull/27324
# Description [CAMEL-25293](https://issues.apache.org/jira/browse/CAMEL-25293) The HiveMQ client acknowledges a QoS 1/2 message to the broker when the consumer's subscribe callback returns, and the callback only hands the exchange to the consumer's thread pool. `HiveMQConsumer.doStop` shut that pool down with `shutdownNow`: the messages still queued were discarded and the ones being processed were interrupted. The consumer is neither `Suspendable` nor `ShutdownAware`, so a route stop or a graceful shutdown stops it first and only waits for the in-flight exchanges, which do not include the queued ones. Every stop under load lost messages the broker considers delivered, without a log and without reaching the route or its error handler. (The documented acknowledgement semantics, not tied to the route's success or failure, are about failed exchanges and stay as they are.) This change keeps the order of `doStop` (unsubscribe and stop the client first, so no new message arrives) and shuts the pool down with `shutdownGraceful`, so the received messages complete. The ExecutorServiceManager's shutdown await termination (10 seconds by default) still bounds the wait; after it the pool is shut down at once as before, so a backlog that takes longer is still lost. A crash also still loses the queued messages, since the client acknowledges them before they are processed (manual acknowledgement would be a separate improvement). `KafkaConsumer`, `GooglePubsubConsumer` and `IggyConsumer` shut their pools down the same way. camel-hivemq is new in 4.23 and not released yet, so there is no upgrade note. Tests: - `HiveMQConsumerStopTest` (new). No broker: the endpoint gets a fake `HiveMQClientAdapter` that keeps the subscribe callback, and the context a thread pool factory that gives the consumer a single thread and signals when the pool is shut down. Three messages are delivered while the first one is being processed (it waits until the pool is shut down), then the route is stopped. - Without the change no message is processed (`Expecting actual: [] to contain exactly ["1", "2", "3"]`): the first is interrupted and the two queued ones are discarded. - With the change all camel-hivemq unit tests pass: 24 tests, 0 failures. The integration tests need Docker and were not run locally. # 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). # 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 the affected module, 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]
