Croway opened a new pull request, #27279: URL: https://github.com/apache/camel/pull/27279
[CAMEL-25197](https://issues.apache.org/jira/browse/CAMEL-25197) follow-up. With a large integration the WebSocket transport could not stay connected. The status snapshot of 316 YAML routes (about 4000 processors) took about 30 s to collect (the cause is filed as [CAMEL-25267](https://issues.apache.org/jira/browse/CAMEL-25267)). The transport collected it on the thread that also sends heartbeats, so the connection was declared dead ("no heartbeat") and dropped about every 65 s, and `hello`, which collected a full status for its `runtime` section, took 30 s after each reconnect. - Snapshots are collected on their own thread (`CliConnectorSnapshots`) and handed to the scheduler, which alone sends, so heartbeats and action results are never held up. - `hello` uses the new `CliSnapshotProducer.runtime()` (default method, `LocalCliConnector` collects only that section). - The next snapshot round waits at least as long as the previous one took, so a slow status does not keep a CPU busy. Tested: the module tests (34) pass. End to end through the Kaoto Kompanion with 316 extra routes per app, on Camel Main, Spring Boot (JDK and Spring clients) and Quarkus (JDK and Vert.x clients): `hello` arrives about 1 s after connecting, and every app stays on its first connection throughout functional checks, a load phase and `stop`. Before the fix the same apps reconnected about every 65 s. _Claude Code on behalf of Croway_ -- 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]
