[
https://issues.apache.org/jira/browse/CAMEL-25566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126586#comment-18126586
]
Serdar Gökay commented on CAMEL-25566:
--------------------------------------
Thanks, I'm working on this and will open a pull request. I don't have
permission to assign the issue; could a committer assign it to me?
Planned shape:
* a new consumer option {{nodes}} on milo-client: a comma-separated list of
node IDs, or a {{file:}} or {{classpath:}} resource with one node ID per line,
where blank lines and lines starting with # are ignored. OPC UA allows commas
in string node IDs but no line breaks (OPC 10000-3, 8.2.4), so the resource
form also carries node IDs that contain commas. {{node}} keeps its current
meaning.
* a {{CamelMiloNodeId}} header on consumer exchanges. The body stays the
{{DataValue}}.
* a consumer registers all its monitored items in one CreateMonitoredItems
request, which Milo splits by the server's MaxMonitoredItemsPerCall.
A correction to the description: today's single-node consumer does not send a
Bad-status exchange when the connection is lost, so this change will not add
one.
While testing I found that since the Milo 1.x migration (4.16), a stopped
milo-client consumer does not delete its monitored item, and failed monitored
item creations are ignored. I filed CAMEL-25599 for that, with its own PR
because it also affects 4.18.x, and will base this change on that fix.
_Claude Code on behalf of etzel-mes_
> 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: Major
> Fix For: 4.24.0
>
>
> 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)
