allthingssecurity opened a new pull request, #28258:
URL: https://github.com/apache/camel/pull/28258

   # Description
   
   [CAMEL-25837](https://issues.apache.org/jira/browse/CAMEL-25837)
   
   With `queueConsumerMode=Poll` the hazelcast-queue consumer takes items with 
`IQueue.poll(pollingTimeout)` in its own thread, and a poll removes the item 
from the queue. `doStop` stopped that thread with `shutdownNow`, which 
interrupts it:
   
   - An idle route: the interrupt ends the poll on the caller's side only. The 
poll stays parked on the member until its timeout (`pollingTimeout`, 10 s by 
default) and takes the first item offered in that time, which nobody routes. 
This happens at every stop of the route (stop, restart, failover, shutdown) 
while producers keep offering.
   - An exchange in flight: the processor was stopped (`super.doStop()`) before 
the thread was done and the interrupt ends any blocking call of the route, so 
the exchange failed silently and its item was lost, also with a graceful 
shutdown.
   
   Changes (`HazelcastQueueConsumer`):
   - The consumer still waits up to `pollingTimeout` for an item, but in 
`IQueue.poll` calls of at most one second, so it sees a stop within a second. 
An idle consumer now makes one poll call per second instead of one per 
`pollingTimeout`.
   - `doStop` no longer interrupts the thread: it waits for the current poll 
and exchange (graceful executor shutdown, bounded by 
`shutdownAwaitTermination`) and stops the processor afterwards.
   
   Without the one-second calls, the graceful wait would last up to 
`pollingTimeout`, which is 10 s by default like `shutdownAwaitTermination`, so 
the stop would time out and interrupt the poll again.
   
   The listen mode (the default) is unchanged. No option changed, so no upgrade 
guide entry.
   
   Tests:
   - New `HazelcastQueueConsumerPollStopTest` (3 tests, an embedded Hazelcast 
member). Without the change all three fail: the item offered after the stop is 
taken from the queue (`expected: <1> but was: <0>`, in 
`itemOfferedAfterTheRouteStoppedStaysInTheQueue` and 
`longPollingTimeoutWaitsForAnItemAndStillStopsPromptly`), and the exchange in 
flight never reaches the mock (`Expected: <1> but was: <0>`). With the change 
all three pass.
   - `longPollingTimeoutWaitsForAnItemAndStillStopsPromptly` uses 
`pollingTimeout=60000`: an item offered after 3 s of waiting is routed, the 
route stops in less than 5 s, and an item offered afterwards stays in the 
queue. With a single `poll(pollingTimeout)` and the graceful stop, it fails 
(`Stopping the route took 10004 ms`).
   - camel-hazelcast unit tests with the change: 245 run, 0 failures, 1 error 
(`HazelcastUserConfigSerializationFilterWarningTest.warnsForUserClientConfigWithoutFilter`:
 a client that cannot reach a cluster here; it errors the same way without the 
change), 1 flake 
(`HazelcastAggregationRepositoryRoutesTest.checkAggregationFromTwoRoutes` 
failed once and passed on the rerun; it does not use the queue consumer).
   
   How it was found: variant analysis of CAMEL-25790 (a consumer with its own 
loop and executor, and what its stop does to that loop), 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-25837](https://issues.apache.org/jira/browse/CAMEL-25837).
   
   # 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]

Reply via email to