[
https://issues.apache.org/jira/browse/CAMEL-25268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-25268:
-----------------------------------
Fix Version/s: 4.24.0
Assignee: Claus Ibsen
> camel-cli-connector - the file transport should not let a slow status hold up
> actions
> -------------------------------------------------------------------------------------
>
> Key: CAMEL-25268
> URL: https://issues.apache.org/jira/browse/CAMEL-25268
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.24.0
>
>
> The file transport ({{FileCliConnectorTransport}}) does all its work on a
> single thread: every second (100 ms when debugging) {{task()}} polls for
> action files, then collects the status, then (every second round) the trace,
> debug, history, error, receive and activity snapshots.
> On a large integration the status can take tens of seconds to collect (316
> YAML routes / ~4000 processors took about 30 s, see CAMEL-25267). While it
> runs:
> * an action file is only picked up when the next {{task()}} starts, so it can
> wait up to the full collection time. The CLI waits 10 s for the output file
> by default ({{ActionBaseCommand.getJsonObject}}), so {{camel cmd ...}}
> actions against a large integration can time out intermittently.
> * deleting the lock file ({{camel stop}}) is only noticed when the next
> {{task()}} starts.
> * the debug snapshot (breakpoints) waits behind the status.
> * with a fixed 1 s delay after a 30 s collection, one CPU core is busy almost
> all the time.
> The WebSocket transport had the same problem, shown as dropped connections
> (the heartbeat was starved), and was fixed in the CAMEL-25197 follow-up (PR
> https://github.com/apache/camel/pull/27279) by collecting snapshots on their
> own thread and waiting at least as long as the last collection took.
> Possible changes for the file transport:
> # poll for actions on a separate thread from snapshot collection (actions are
> cheap and need low latency; the dispatcher is not thread-safe, so actions
> should still run one at a time)
> # schedule the next status round after max(delay, time the last round took)
> CAMEL-25267 (making the status cheap to collect) fixes the cause for both
> transports; this issue is about the file transport staying responsive when
> collection is slow anyway.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
