[
https://issues.apache.org/jira/browse/CAMEL-25691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serdar Gökay reassigned CAMEL-25691:
------------------------------------
Assignee: Serdar Gökay
> camel-milo - the consumer never recovers when its subscription stops
> publishing (watchdog, Bad_Timeout)
> -------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25691
> URL: https://issues.apache.org/jira/browse/CAMEL-25691
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
> Reporter: Serdar Gökay
> Assignee: Serdar Gökay
> Priority: Minor
>
> {{SubscriptionManager.SubscriptionListenerImpl}} implements only
> {{onTransferFailed}} (tears the connection down and rebuilds it) and
> {{onStatusChanged}} (logs at INFO). {{onWatchdogTimerElapsed}} keeps the
> no-op default of {{OpcUaSubscription.SubscriptionListener}}.
> Consequence: when the server drops the subscription while the session stays
> alive (server-side subscription lifetime expired, server restarted with
> session reuse, subscription id no longer known), the publish response carries
> {{Bad_NoSubscription}} and Milo's {{PublishingManager}} stops sending publish
> requests for that subscription without reporting an error. Milo then fires
> the watchdog timer (publishing interval × (maxKeepAliveCount + 1) × 1.5) and
> leaves the reaction to the listener. Because our listener ignores it, the
> route keeps its last value forever: no exchange, no log line, no reconnect. A
> status change to {{Bad_Timeout}} (subscription timed out on the server) is
> logged at INFO and otherwise ignored for the same reason.
> Why this matters: the consumer feeds historians, MES systems, Unified
> Namespace brokers and alarm handling, usually on unattended edge hosts. A
> subscription that silently stops is worse than a broken connection, because
> every downstream system keeps a stale value that still looks current.
> Industrial OPC UA clients treat the watchdog and {{Bad_Timeout}} as "recreate
> the subscription and its items" and report the loss, so an operator sees the
> gap instead of a frozen value.
> Proposal:
> * implement {{onWatchdogTimerElapsed}}: WARN with the subscription id, then
> recreate the subscription and its monitored items. The existing connection
> rebuild ({{handleConnectionFailure}}) already does this and is the simplest
> first version; a lighter "delete and recreate only this subscription" variant
> can follow if the rebuild proves too heavy.
> * treat {{onStatusChanged}} with a bad status ({{Bad_Timeout}},
> {{Bad_NoSubscription}}, {{Bad_SubscriptionIdInvalid}}) the same way, at WARN
> instead of INFO.
> * a test with the embedded server that drops the subscription (or lets its
> lifetime expire) and asserts that values flow again without restarting the
> route.
> The subscription's keep-alive and lifetime counts are left as they are; that
> is a separate topic.
> I can send a PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
