[
https://issues.apache.org/jira/browse/CAMEL-25692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serdar Gökay reassigned CAMEL-25692:
------------------------------------
Assignee: Serdar Gökay
> 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
> Assignee: Serdar Gökay
> Priority: Minor
>
> 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)
