davsclaus opened a new pull request, #26925: URL: https://github.com/apache/camel/pull/26925
Follow-up to CAMEL-25041, which replaced the JDK `WatchService` with a scan of the watched folder. **camel-jbang was reloading the routes because of its own state file.** `camel run` keeps the properties of the run it is doing in `.camel-jbang/camel-jbang-run.properties` and writes it more than once while starting. The scan reported each write, the file ends in `.properties`, so the strategy treated it as a properties change and reloaded the routes for it. Measured on the same example before and after CAMEL-25041: ``` WatchService (10 s poll): 1 "Reloading properties: .../.camel-jbang/camel-jbang-run.properties" scan (1 s): 2 ``` The 10 s poll coalesced both writes into one batch, so it happened once and was merely pointless. At 1 s they are two changes, so the application reloaded twice a second apart — and that is not harmless. An example whose file consumer calls a rest route in the same application had the call in flight answered 404 by a rest route that the second reload was tearing down and rebuilding: ``` 11:15:12.227 INFO Routes reloaded summary (total:2 started:2) 11:15:13.230 ERROR HTTP operation failed invoking http://localhost:8080/stock/CAMEL-MUG with statusCode: 404 11:15:14.248 INFO Routes reloaded summary (total:2 started:2) ``` **A dot directory holds state, not sources, so the scan skips it** — as it already skips the compile work directory (CAMEL-24862). `.camel-jbang`, `.camel`, `.git` and `.idea` are then all out of the way. This also matters for cost: registering directories once meant the size of `.git` did not matter, but a scan every couple of seconds walks it for nothing. A route file inside a dot directory is no longer watched, which is the intended consequence and is noted in the upgrade guide. **The scan interval goes back to 2000 ms**, the previous default, so `setPollTimeout`'s default is unchanged after all and the upgrade guide no longer has to warn about it. A longer interval also groups more of one save together — two files written a second apart are one change at 2000 and two at 1000 — and one change per save is exactly what the batching of CAMEL-25041 wants. macOS still improves from up to ten seconds to two. Verified on the example that failed: 3 of 3 steps, zero spurious property reloads, zero 404s. `FileScanReloadTest` gains a case for the dot directory (8 tests); the live-watcher `FileWatcherResourceReloadStrategyTest` and `RouteWatcherReloadStrategyTest` pass, and a full reactor build. Found while checking CAMEL-25041 against the local-model benchmark before a long run: the extra reload made one rung of the ladder fail for a reason that had nothing to do with the model. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Bp3538HRBPMQkb5ta9xRaj -- 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]
