davsclaus opened a new pull request, #29846: URL: https://github.com/apache/camel/pull/29846
Part of [CAMEL-26911](https://issues.apache.org/jira/browse/CAMEL-26911), item B5: a slow action blocked `camel stop` and the status. ## Problem One connector thread looks for the lock file (which `camel stop` deletes), writes the status file, and runs the actions. A `camel cmd send` that waits (a `--poll` of an empty endpoint, or an InOut send to a slow route) held that thread up to its timeout: - `camel stop` waited for the send: 22.2 s in the test below. - `camel get`, `ps` and the TUI showed a status that no longer updated. - Other actions (route stop, dumps, ...) queued behind the send. ## Fix `LocalCliConnector.dispatchAsync` now runs every send off the connector thread, the same way as a repeated send already did (CAMEL-26767): - A single send runs on a new `cli-send` pool of one thread with a queue of 100. Sends still run one at a time and in order, as they did on the connector thread. A full queue is answered "Busy". - A repeated send keeps its pool of two. - Both share one `send(...)` helper. The transport cancels a send when the client gives up the request (deletes its action file), as before. - `doActionSendTask` (used by a transport that dispatches on its own thread) uses the same `sendResult` as the async path. ## Tests `LocalCliConnectorFileTransportTest`: - `slowSendDoesNotBlockTheStatusNorStop`: while an InOut send to a slow route waits, a route-stop action is applied and shows in the status file, and deleting the lock file triggers sigterm. **This test fails on main.** - `sendsAreAnsweredInOrderOnceTheSlowOneIsDone`: a second send waits for the slow one, and both are answered. The whole `camel-cli-connector` module passes (113 tests). ## End-to-end A patched launcher ran an integration in the background, started `camel cmd send --poll --endpoint=seda:empty`, then ran `camel get` and `camel stop`: | | `camel stop` | |---|---| | main | 22.2 s | | this PR | 4.3 s | The send client still waits out its own timeout once the integration has gone, as it did before this change (`ActionClient` does not check whether the process is alive). That is left for a follow-up. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_012nJsFsjqqFiwroeHRWaKbS -- 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]
