[
https://issues.apache.org/jira/browse/CAMEL-25661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127225#comment-18127225
]
Claus Ibsen commented on CAMEL-25661:
-------------------------------------
Measured on Oct 14 with the local-model benchmark (qwen3.6 35B-A3B, 21
examples, the same harness in every run):
* With today's 2000 ms scan, an accepted {{camel_write_file}} or
{{camel_edit_file}} call took a median of 2.52 s (mean 2.59 s, p90 4.20 s; 294
writes over 3 runs). That is 4.2 minutes of tool time per run.
* With the scan at 250 ms, a median of 1.49 s (mean 1.75 s, p90 3.61 s; 99
writes). This is an upper bound for reloading at once, measured with a patched
camel-support for one run only. It is 2.9 minutes per run.
So each write answers about 1 s sooner (-41%), which is about 1.3 minutes per
benchmark run (~3%).
The reload through the CLI connector, as proposed above, gets only part of that
while the connector reads its action files once a second (every 100 ms in debug
mode). It also needs a "scan now" in the reload strategy, and care so that one
change is not reloaded twice.
A cheaper variant gets most of the gain:
* make the dev-mode scan interval an option
({{FileWatcherResourceReloadStrategy.setPollTimeout}} cannot be set from
configuration today);
* have {{camel_run}} (the AI tool) start integrations with 500 ms.
The tools write a whole change in one call, so the shorter interval does not
split a save. {{camel run}} for people keeps 2000 ms.
Lowering this to Minor. Worth another look together with the WebSocket
transport of the CLI connector (CAMEL-25197), where an action is picked up at
once.
_Claude Code on behalf of davsclaus_
> camel-jbang - AI write tools reload the file at once, not at the next folder
> scan
> ---------------------------------------------------------------------------------
>
> Key: CAMEL-25661
> URL: https://issues.apache.org/jira/browse/CAMEL-25661
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> {{camel_write_file}} and {{camel_edit_file}}, the shared AI tools in
> camel-jbang-core that the Camel MCP server and {{camel ask}} use, write the
> file and then wait for dev mode to reload it. {{ReloadOutcome.await}} polls
> the integration's log every 500 ms, and the tool answers with the reload
> outcome and what the routes logged after it.
> Dev mode finds the change on its next folder scan:
> {{FileWatcherResourceReloadStrategy}} scans every 2000 ms and reports a file
> once it has been unchanged for 200 ms (CAMEL-25032). So every accepted write
> waits 0.2-2.2 s, about 1 s on average, before the reload even starts.
> The tool knows exactly which files it wrote, and when. It could hand them to
> the reload strategy at once, as one batch, through the CLI connector (which
> already has a {{reload}} action), and record their modification time and size
> as seen, so the next scan does not reload the same change again.
> h3. Benefit
> * Each write answers about a second sooner, for agents and for people using
> {{camel ask}} or the MCP server from an IDE.
> * In a local-model benchmark run (21 examples, about 114 accepted writes per
> run) that is about 2 minutes per run.
> h3. Care
> * No double reload: a second reload of the same change rebuilds a rest route
> while an HTTP call may be in flight, and that call is answered 404.
> * Properties and routes written together stay one batch, properties first
> (CAMEL-25041).
> * Files changed outside the tools (by an editor) are still found by the scan,
> as today.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
