allthingssecurity opened a new pull request, #28264: URL: https://github.com/apache/camel/pull/28264
# Description [CAMEL-25843](https://issues.apache.org/jira/browse/CAMEL-25843) With `reliable=true` the hazelcast-topic consumer listened with a plain `MessageListener`. A reliable topic keeps its messages in a ringbuffer of limited capacity; when a listener falls behind by more than that, Hazelcast removes a listener that is not loss tolerant for good (`MessageRunner.accept` cancels it; `ReliableMessageListenerAdapter.isLossTolerant()` is false). After one burst that a slow route could not keep up with, the route stayed started and received nothing again, and Camel logged nothing. Changes: - New `CamelReliableMessageListener` (a `ReliableMessageListener`, loss tolerant): logs a WARN with the number of messages lost and goes on with the oldest message still in the ringbuffer; starts with the messages published from then on, as before. - `HazelcastTopicConsumer` uses it for a reliable topic. The plain topic is unchanged. No option changed, so no upgrade guide entry. Tests: - New `HazelcastReliableTopicConsumerLossTest` (embedded member, ringbuffer capacity 10): the route is busy with a first message while 30 more are published, then one more is published. Without the change it is never received (`Expected: <1> but was: <0>`); with the change it is, and a WARN reports the messages that were overwritten (about 20; the exact number depends on how far the ringbuffer has moved when the listener reads again). - camel-hazelcast unit tests with the change: 243 run, 0 failures, 1 error (`HazelcastUserConfigSerializationFilterWarningTest.warnsForUserClientConfigWithoutFilter`: a client that cannot reach a cluster here; it errors the same way without the change). How it was found: variant analysis of CAMEL-25815 (the server side ends a consumer's subscription and the consumer never subscribes again), then the JUnit test. What was not run: a Hazelcast client (only an embedded member); 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-25843](https://issues.apache.org/jira/browse/CAMEL-25843). # 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-hazelcast. 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]
