davsclaus opened a new pull request, #29459: URL: https://github.com/apache/camel/pull/29459
## What [CAMEL-26767](https://issues.apache.org/jira/browse/CAMEL-26767): `camel cmd send` sends many messages. Step 2 of [CAMEL-26760](https://issues.apache.org/jira/browse/CAMEL-26760) ("let there be chaos"): an agent that explores chaos rules sends traffic into the routes, and a stubbed broker consumer (`camel run --stub=remote`) is fed with `camel cmd send`, which sent one message per command. ``` $ camel cmd send shop --endpoint=kafka:refunds --body=file:test/chaos/refunds-fails/ --repeat=32 --interval=50ms 2026-11-09 11:24:04.792 28199 --- kafka://refunds : Sent 32 messages (success) (1s838ms) ``` ## Changes - **CLI:** `--repeat=N` sends the message N times (at most 10000) and `--interval=200ms` pauses between two (at most 60s). A summary line replaces the reply table: `Sent 50 messages (48 ok, 2 failed)`, then the errors with their counts. It exits with `1` when a message failed. `--poll` and `--reply-file` cannot be repeated (usage error). The wait for the answer adds the pauses and a second per message. - **Folder of messages:** `--body=file:<folder>` sends the files in name order, one message per file, leaving out hidden files. `001.properties` holds the headers of `001.json`. `--header` goes with every message, and the headers of a file win. With `--repeat` it goes round the files again. This is the feed folder of a chaos scenario (`test/chaos/<name>/`, CAMEL-26761). The integration reads the folder relative to its working directory, as it reads the file of a single body, so the AI tools' check for a file outside the project covers it the same way. - **CLI connector:** `RepeatedSend` sends the messages through the send dev console on a thread of its own (`dispatchAsync`, as the semantic actions do). So the status and the other actions keep going: `camel get chaos` answered in 1s during a 6s send. If the client gives up the request, the transport cancels it and the loop stops. An endpoint that is not there stops it at the first message. - **AI and MCP:** `send_message` (camel ask) and `camel_runtime_send` get `repeat` and `interval`, and their descriptions say how to feed a stubbed broker consumer. - **Bug fix in the send dev console:** a `file:` body was sent as a `FileInputStream` and closed as soon as `producer.send` returned. An endpoint that hands the message to another thread (seda, or a stub, which is a seda queue) then read a closed stream: `TypeConversionException ... Bad file descriptor`. A single send usually won the race. In a repeat, 20 of 32 messages failed. The console now sends the content of the file (`byte[]`). - **Docs:** "Sending many messages" in the CLI development tools page; the `cmd send` command page and the golden help are regenerated. - **Not changed:** the TUI's own `tui_send_message` tool. That comes with the TUI explore step. ## Tests - `LocalCliConnectorSendActionTest` (new): a repeat with a pause; a folder in name order with its headers, again with a repeat and a common header; failures counted with their errors; an endpoint that is not there; poll, too many messages and an empty folder refused; a repeat of 1 is a plain send. - `CamelSendActionResultTest`: the action options, the summary line and exit code, the wait time; usage errors. - `RuntimeHelperTest.sendTimeoutCountsTheMessages`, `RuntimeToolsWiringTest` (new signature). - `SendDevConsoleTest.testSendConsoleFileBodyToAQueue`: a file body to a seda route that reads it 200ms later. - Local runs, all passing: camel-console `*DevConsoleTest` (205), camel-cli-connector (103), camel-jbang-core `CamelSendAction*Test` + `RuntimeHelperTest` + `CliHelpGoldenTest` + `ToolRegistry*Test` + `AskTools*Test`, camel-jbang-mcp (all). - End to end with `camel run --stub=remote --chaos` and a rule `route=refunds error rate=every:4`: 32 messages from a folder of 2 → refunds completed 24, failed 8. Before the console fix it was 4 completed, 28 failed, 20 of them "Bad file descriptor". _Claude Code on behalf of Claus Ibsen_ -- 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]
