[ 
https://issues.apache.org/jira/browse/CAMEL-25448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126816#comment-18126816
 ] 

Claus Ibsen commented on CAMEL-25448:
-------------------------------------

Another case, found while testing the monitor on main: it also loses its own 
one-way actions, not only the answers of other clients.

* {{MonitorContext.fireAction}} (route start/stop/suspend/resume from F10 Run, 
the Routes tab and the Overview; reset stats) writes {{<pid>-action.json}} and 
returns without waiting for the connector.
* The Diagram tab reloads the route topology about once a second through 
{{executeAction}} ({{CamelMonitor}} tick -> {{refreshDiagramIfNeeded}} of both 
diagram tabs), also while another tab is on screen, and the connector reads the 
shared file about once a second.
* So the next {{route-topology}} request overwrites the route command before 
the connector reads it. F10 > Stop Routes did nothing in 2 of 2 tries on a 
timer route; watching the action file showed a {{route-topology}} write every 
~1 s, answered in ~0.3 s.

So this issue should move {{fireAction}} to the per-request files too, not only 
{{executeAction}}. Separately, refreshing only the diagram of the tab on screen 
would drop the needless topology requests.

_Claude Code on behalf of davsclaus_

> camel-jbang - the monitor uses per-request action files, so it cannot lose 
> other clients' answers
> -------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25448
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25448
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jbang
>            Reporter: Claus Ibsen
>            Priority: Minor
>             Fix For: 4.24.0
>
>
> The camel-jbang monitor sends actions through the shared <pid>-action.json / 
> <pid>-output.json pair, and deletes the output file before and after each of 
> its actions (MonitorContext.executeAction). A client asking the same 
> integration at the same moment (a camel command, a script, an agent in the 
> monitor's AI panel) loses its answer or reads the monitor's. Found while 
> measuring CAMEL-25438: the monitor deleted the answer of the measuring script.
> Since 4.21 the connector also takes <pid>-action-<requestId>.json and answers 
> in <pid>-output-<requestId>.json (RuntimeHelper, used by camel ask and the 
> MCP server).
> Proposal: the monitor uses the per-request files.
> * No client can lose another's answer.
> * The connector answers every pending action file in one loop, so the monitor 
> can drop its one-action-at-a-time lock per integration: several tabs' actions 
> are answered together in one loop instead of one loop each (with the faster 
> connector loop, about 0.1 s).
> * Fallback: the monitor attaches to any running integration, and a connector 
> older than 4.21 only knows the shared file: use the Camel version of the 
> status file to pick the protocol.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to