etzel-mes opened a new pull request, #28511: URL: https://github.com/apache/camel/pull/28511
# Description Follow-up of CAMEL-25912 (#28371). When a consumer-side failure tears the connection down, `handleConnectionFailure()` disposed it with `OpcUaClient.disconnect()`, which sends CloseSession and waits for it, under the manager lock. On a silent network drop the CloseSession is not answered, so the wait lasted 6–7 s on a real server (until the channel's next reconnect attempt failed), and the connection was rebuilt only after it. Measuring it corrected the premise of the issue: no other thread waited on the manager lock for it. The caller is the thread that starts or stops a consumer route, and other route starts and stops in the same CamelContext wait on the context's own route lock, so moving a synchronous disconnect out of the manager lock would not have shortened anything. What helps is not waiting at all. What changes: - A connection torn down because it failed (`handleConnectionFailure()` and the "Failed to set subscriptions" path of the reconnect) is closed with Milo's `OpcUaClient.disconnectAsync()` without waiting; a failed disconnect is still logged as `Failed to disconnect client`. In Milo 1.1.8 `disconnect()` is `disconnectAsync().get()`, so this is the same operation without the wait; it runs on Milo's threads, not on the `MiloClient` executor or the `MiloClientReconnect` thread. - The connection is marked closed before either disconnect, as before, so the session it closes is not reported as a loss. - Unchanged: disposing the manager (component stop) still waits for the clean disconnect; options, defaults and log texts are unchanged, so no doc change. Tests: new `CommunicationLossTest.failedConnectionIsRebuiltWithoutWaitingForItsSessionToClose` (embedded server behind the TCP relay, `requestTimeout=1000`): after `silence()`, a registration times out and the registering thread must never be inside `OpcUaClient.disconnect`; the connection is then rebuilt and both consumers end on the good value. It fails on the unmodified code (connect to failure 6.5 s against 1.3 s) and with only `handleConnectionFailure()` reverted. Module `-Psourcecheck verify` with `-Dsurefire.rerunFailingTestsCount=0`: 126 tests, 0 failures, 1 skipped (as upstream). Measured on a real server (opc-plc 2.15.4, server and client with `--cpus=1`, silent drop with iptables, one CamelContext with consumers, a 50-node consumer route started into the drop, another route stopped and started every 2 s): | scenario | before | after | |---|---|---| | route start 1 s into a 45 s drop: dispose under the lock / route start / other route op waiting (2 runs) | 6.05–6.06 s / 19.3–19.6 s / 15.2–15.5 s | ≤ 30 ms / 13.4–13.7 s / 9.4–9.7 s | | route start after the session is declared lost, 75 s drop (2 runs) | 7.0 s / 12.5–12.8 s / 8.4–8.5 s | < 25 ms / 5.6–5.8 s / 1.6–1.8 s | | 16–18 s blip, link back while the old CloseSession is pending: restore to first good value (3 runs) | 1.5 / 1.5 / 4.4 s | 1.1 / 1.6 / 1.6 s | The rest of a route start into a drop is its CreateMonitoredItems call waiting until the keep-alive declares the session lost, as designed. Reconnect attempts keep the same 15 s cadence; it now starts 6–7 s earlier. In the blip runs both versions leave the old session on the server until its session timeout: the late CloseSession either stays in the dead TCP connection or is rejected with `BadSecureChannelIdInvalid` on the new channel, and it never disturbed the new session. Healthy runs: no teardown, no change. Not done: when the manager is disposed while `performConnect()` is connecting, the new connection is not disconnected (pre-existing, rare). CAMEL-26113 and CAMEL-26114 stay separate. Fixes CAMEL-26112. @davsclaus @oscerd # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. _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]
