etzel-mes commented on PR #27910: URL: https://github.com/apache/camel/pull/27910#issuecomment-6198200622
Thanks for the review. **Lock.** Intentional, and I added the Javadoc note. The `OpcUaSubscription` is shared with `registerItems` and `unregisterItems`, which already run `createMonitoredItems` / `deleteMonitoredItems` under `lock` (through `whenConnected`), and `handleConnectionFailure` disposes the client under it. Milo's `OpcUaSubscription` has no synchronisation of its own, so `lock` is what serialises access to it. `performConnect` can run outside the lock because it works on a new client and a new subscription that nobody else sees yet; the recreation changes the subscription the consumers are using. Building a replacement outside the lock would still need the lock for `createMonitoredItems` and the swap, and a consumer started in between would register its items on the dead subscription. In the case this change is for, a server that dropped the subscription and answers immediately, the three calls take a few milliseconds in the tests. **Timeout.** Every service call goes through Milo's `UascClientMessageHandler`, which fails a request with `Bad_Timeout` after the request timeout hint (`OpcUaClientConfig.requestTimeout`, 60 s by default; the endpoint's `requestTimeout` option sets it). So the worst case against an unresponsive server is one request timeout per call, after which the catch block falls back to `handleConnectionFailure`, the path a failed reconnect takes today. The Javadoc now says so. The review mentions a process note that I cannot see on the PR; happy to address it if you post it. _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]
