etzel-mes opened a new pull request, #27910: URL: https://github.com/apache/camel/pull/27910
# Description Fixes [CAMEL-25691](https://issues.apache.org/jira/browse/CAMEL-25691). `SubscriptionManager.SubscriptionListenerImpl` ignored `onWatchdogTimerElapsed` and only logged `onStatusChanged`. When the server drops the subscription while the session stays alive (subscription lifetime expired after a network or scheduling stall, server configuration reload, `Bad_NoSubscription` on publish), Milo stops sending publish requests, fires the watchdog and leaves the reaction to the listener. The consumer then kept its last value forever: no exchange, no reconnect, one INFO line at most. `Bad_Timeout` is the same case reported by the server: Milo resets the subscription before the callback, and nothing created it again. With this change the consumer recreates the subscription inside the existing session on both callbacks: `delete()` best effort (`reset()` if the delete fails), `create()`, `createMonitoredItems()` on the same `OpcUaSubscription` and the same monitored items, which Milo keeps across `reset()` together with their client handles and listeners. The work is handed to the manager's executor and runs under the connection lock, never on Milo's delivery thread. A guard skips callbacks that belong to a disposed connection or to a subscription that was already recreated. If the recreation fails, the existing `handleConnectionFailure` rebuilds the connection as before. ## Why recreate the subscription instead of rebuilding the connection A `MiloClientConnection` is shared by every consumer and producer with the same connection parameters. Rebuilding it for one dead subscription closes the session, leaves writes, method calls and reads with "No connected" until the reconnect finishes, re-subscribes every consumer and opens a new session on the server. PLC-integrated OPC UA servers (Siemens S7-1500/S7-1200 and similar controllers) allow only a small number of sessions, and a session whose CloseSession did not reach the server counts against that limit until its timeout expires. Recreating the subscription in place is the pattern Milo documents for `reset()`, does not touch the other users of the connection and leaves the session count unchanged. The full rebuild stays as the fallback. Not changed: `onTransferFailed` still rebuilds the connection; value changes during the gap are not republished (the monitored items deliver their current value again after recreation, as after a reconnect). Both are documented. ## Tests `MonitorItemLifecycleTest`: * `subscriptionThatStopsPublishingIsRecreatedInTheSameSession`: shortens the watchdog through Milo's public API (`setMaxKeepAliveCount(1)`, `modify()`), deletes the subscription through the connection's own session (the server then answers the pending publish requests with `Bad_NoSubscription`), and asserts that a new value arrives, the `OpcUaClient` is the same instance and the subscription id changed. The watchdog fires after about 0.4 s. * `subscriptionThatTimesOutOnTheServerIsRecreatedInTheSameSession`: the embedded server sends a `Bad_Timeout` status change and removes the subscription. Both fail without the fix (timeout after 30 s, last value stays the old one) and pass with it; the class was run repeatedly with `-Dsurefire.rerunFailingTestsCount=0`. `./mvnw -pl components/camel-milo -Psourcecheck verify`: 57 tests, 0 failures. Docs: a "Subscriptions that stop publishing" section in `milo-client-component.adoc` (catalog copy identical), and a note in the 4.24 upgrade guide under the existing camel-milo section. @davsclaus @oscerd # Target - [x] I checked that the commit is targeting the correct branch (note that Camel 3 uses `camel-3.x`, whereas Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there's a JIRA issue (CAMEL-25691) # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [x] I have run `mvn clean install -DskipTests` locally from root directory and I have committed all auto-generated changes. - [x] I used AI to generate this pull request. The hand-written code and tests were reviewed and verified by me. _Claude Code on behalf of etzel-mes_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
