[
https://issues.apache.org/jira/browse/CAMEL-25566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126492#comment-18126492
]
Claus Ibsen commented on CAMEL-25566:
-------------------------------------
Yeah that is a good - indeed industires have many devices to track, so PR is
welcome
> camel-milo - Subscribe to many OPC UA nodes from one consumer
> -------------------------------------------------------------
>
> Key: CAMEL-25566
> URL: https://issues.apache.org/jira/browse/CAMEL-25566
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Affects Versions: 4.22.1
> Reporter: Serdar Gökay
> Priority: Minor
>
> h3. Use case
> Industrial data is often published from OPC UA servers (SCADA gateways, OPC
> servers, PLC-embedded servers) to a messaging layer such as MQTT, so that
> applications and dashboards can follow current values without talking OPC UA
> themselves. A typical installation follows thousands to tens of thousands of
> tags on a single server.
> The milo-client consumer already fits this well: it uses an OPC UA
> subscription, so the server pushes data changes and no polling is needed.
> However, each milo-client endpoint monitors exactly one node. Following N
> tags therefore means N consumers, and since a route has one input, N routes,
> for example generated from a route template.
> h3. What we observe with many nodes
> * Each consumer registers its monitored item on its own, so startup makes one
> CreateMonitoredItems call per node. The internal SubscriptionManager can
> already create several items in one call, but the consumer passes a single
> item each time.
> * Thousands of routes add startup, reload and memory cost that is unrelated
> to the OPC UA work itself.
> * Eclipse Milo itself handles one subscription with thousands of monitored
> items. Other Milo-based products group monitored items per server and rate.
> h3. What would help
> A way to follow a set of nodes on one server from one consumer, delivering
> one exchange per data change with the node identity in a header, so that a
> single route can forward all changes (for example to an MQTT topic derived
> from the node). How the node set is expressed, for example a list, a resource
> or a browse root, is open; the maintainers know the component's conventions
> best.
> If it is useful, one possible shape:
> * a consumer option carrying a list of node IDs, or a reference to a resource
> listing them;
> * monitored items created in batches that respect the server's operation
> limits;
> * per-exchange headers for node ID, status code and source/server timestamps;
> * on connection loss, a Bad-status exchange per node, and resubscription on
> reconnect (similar to today's single-node behavior).
> Related: CAMEL-17319 (browse support, which can produce such a node list),
> CAMEL-25145 (subscription parameters applied per endpoint in 4.23.0).
> We are happy to test a proposal against Ignition and a Milo test server with
> 10,000 nodes, and to contribute a PR if the direction is agreed.
> _Claude Code on behalf of etzel-mes_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
