Serdar Gökay created CAMEL-25692:
------------------------------------
Summary: camel-milo - retry monitored items that fail to create
instead of dropping them
Key: CAMEL-25692
URL: https://issues.apache.org/jira/browse/CAMEL-25692
Project: Camel
Issue Type: Improvement
Components: camel-milo
Reporter: Serdar Gökay
Since CAMEL-25566/CAMEL-25599 (PR 27780) a monitored item whose
{{CreateMonitoredItems}} operation result is bad is reported once to the route
as a {{DataValue}} with that status code (for example {{Bad_NodeIdUnknown}}),
logged at WARN and removed from the subscription. It is never tried again: the
node only comes back when the route is restarted. A bad service result rebuilds
the whole connection, which recreates all items once.
Cases where this is not enough:
* the node does not exist yet when the route starts (PLC program or tag
configuration deployed after the integration, server started with an empty
address space and filled by its own startup)
* server restart where the address space is rebuilt after the session is
re-established, so the items recreated by the reconnect fail
* a node temporarily removed and re-added by an engineering change,
{{Bad_TooManyMonitoredItems}} during a peak
The consumer already has the mechanism:
{{SubscriptionManager.Subscription.badSubscriptions}} with a {{resubscribe}}
scheduled every {{reconnectTimeout}} (10 s), used today only for a node whose
namespace URI is not known. Industrial OPC UA clients behave the same way for
every failed item: the item stays "waiting" and is retried on a fixed slow
cadence for the lifetime of the connection, while the value stays marked as not
yet available.
Proposal:
* put items with a bad operation result into {{badSubscriptions}} and let the
existing 10 s {{resubscribe}} create them again; report the bad status to the
route and WARN once on the first failure only, stay quiet while retrying, and
deliver values normally once the create succeeds
* keep the connection rebuild for a bad service result
* a dead subscription (no publish responses) is a different case, tracked in
CAMEL-25691
One prerequisite: {{MiloClientConnection}} passes
{{Stack.sharedScheduledExecutor()}} to the {{SubscriptionManager}}, so
{{resubscribe}} runs blocking {{createMonitoredItems}} calls on Milo's shared
scheduler, which is sized to the processor count and also runs the session FSM
reconnect timers. Measured while preparing CAMEL-25599: on a host with one
processor, a client that was retrying one failed item never recovered from a
server outage, because the blocked retry occupied the scheduler thread the
reconnect timer needed; that is why CAMEL-25599 landed without the timer retry.
The retry should therefore run on an executor owned by the component, obtained
from the {{CamelContext}} {{ExecutorServiceManager}} as other components do,
and stopped with the endpoint.
I can send a PR, after PR 27906 (CAMEL-25671) and the CAMEL-25690 follow-up
have landed, since they touch the same class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
