Serdar Gökay created CAMEL-25566:
------------------------------------
Summary: 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
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)
