allthingssecurity opened a new pull request, #28322: URL: https://github.com/apache/camel/pull/28322
# Description [CAMEL-25849](https://issues.apache.org/jira/browse/CAMEL-25849) A `disruptor-vm` queue is shared by the CamelContexts of the JVM, but `DisruptorReference` always created the threads of its event handlers with the `ExecutorServiceManager` of the CamelContext whose component created the queue. When that CamelContext stopped, it shut those threads down as part of its own shutdown (after waiting 10 seconds for them), while other CamelContexts still used the queue: their consumers never consumed again (route still Started, nothing logged there), and every message sent to the queue afterwards stayed in the ring buffer as an inflight exchange. Changes: - `DisruptorReference` creates the thread pool with the CamelContext of an endpoint that uses the queue (the component's CamelContext when there is none yet), and remembers it for the shutdown and the resize. - `removeEndpoint`: when the last endpoint of that CamelContext is removed while endpoints of another CamelContext remain, the event handlers move to a new thread pool of one of those CamelContexts, as on a reconfiguration (the backlog is published again); one INFO line names the queue and the CamelContexts the threads move from and to. With a single CamelContext nothing changes. No option changed, so no upgrade guide entry. Tests: - New `DisruptorVmFirstContextStopTest`: CamelContext 1 sends to `disruptor-vm:foo` and so creates the queue, CamelContext 2 consumes from it and sends to it. After CamelContext 1 stops, a message sent from CamelContext 2 must be consumed. Without the change it fails (`mock://result Received message count. Expected: <1> but was: <0>`); with the change it passes. - camel-disruptor unit tests with the change: 118 run, 0 failures. How it was found: variant analysis of CAMEL-25846 (an object kept in a static map that depends on the lifecycle of one owner), then the JUnit test. What was not run: several deployments in an application server; 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-25849](https://issues.apache.org/jira/browse/CAMEL-25849). # 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-disruptor. No option 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]
