etzel-mes opened a new pull request, #28272: URL: https://github.com/apache/camel/pull/28272
# Description Since CAMEL-25692 the refused monitored items of a `milo-client` connection are created again every `reconnectTimeout` milliseconds, but which nodes are refused at a given moment, and why, is visible only in DEBUG logs. This adds a read-only `milo-client` dev console (`/q/dev/milo-client`, for example with `camel run --console`). For each connection of the started consumers it lists the endpoint (password masked), the ids of the routes that use the connection, whether its session is active, the number of nodes that have a monitored item on the server, and the refused nodes. A refused node shows the status of the latest attempt to create its monitored item: the refusal of the server, or the failure of the attempt for the nodes that it did not answer, and a reason when the client refused the node without asking the server because its namespace URI is unknown. Text and JSON output (schema generated). The console finds the connections through the consumers of the routes, like the Kafka, Vert.x WebSocket and AWS S3 consoles, so a connection that only producers use is not listed. It reads the state without the lock of the subscription manager, which a service call holds until the server answers, so it answers while an attempt waits for a server that dropped the connection silently. It does not connect, and it shows a connection that is being closed, whose nodes have been reported lost, without a session and without nodes. Tests: `MiloClientDevConsoleTest` (embedded server) covers a server refusal and a client refusal with the exact text output, a node created on the server later (and a namespace added without the node, which turns the client refusal into the server's), a failed attempt (`Bad_Timeout` while the server holds the call, and a node that the same attempt refused without asking the server keeps that refusal), two routes on one connection and a stopped route, two connections of which one loses its session through a TCP relay (it keeps its nodes while the session is inactive, the other one is not affected), a connection without a session, a connection that is being closed while the server holds its `CloseSession` call (no session, no nodes), and the console answering while the server holds the `CreateMonitoredItems` call of a starting consumer, which holds the lock. The relay of `CommunicationLossTest` moves to `TcpRelay` for that. Also checked against a real OPC UA server (node-opcua) with a 20 s silent network drop while a node is refused: the console answered in at most 20 ms while a retry held the lock for 9.9 s, showed the lost session with `Bad_ConnectionClosed` for the node, the refusal again once the session was back, and then the node created. Docs: one paragraph in the component page, after the refused monitored items. Fixes CAMEL-25913. @davsclaus @oscerd # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. _Claude Code on behalf of etzel-mes_ -- 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]
