etzel-mes opened a new pull request, #28219: URL: https://github.com/apache/camel/pull/28219
# Description `MiloClientComponent.setReconnectTimeout` and `MiloBrowseComponent.setReconnectTimeout` set the request timeout of every service call (since the first version of each component), and the delay between two connection attempts was the literal 10000 ms in `MiloClientConnection`. Setting `camel.component.milo-client.reconnectTimeout=2000` to retry faster therefore kept the 10 s delay and made every request time out after 2 s: a request that takes longer, such as a method call, failed with `Bad_Timeout`, the connection was rebuilt, and every consumer of the connection reported `Bad_NoCommunication`. This adds a `reconnectTimeout` option to `MiloClientConfiguration` (label client, default 10000 ms, the previous delay), on both endpoints and through the component configuration, and both component setters now set it. It is the delay before Camel tries again to connect after an attempt failed, at startup or while Camel rebuilds a failed connection. The Milo client still recovers a lost session on its own, with its own timing. A value of 0 or less is rejected, because the client would then retry without pause while the server refuses the connection. `setRequestTimeout` names its parameter `requestTimeout` now. Tests: `ReconnectTimeoutConfigurationTest` (default, endpoint option, both component setters, the request timeout left unset, a value that is not positive) and `CommunicationLossTest#consumerStartedWithoutTheServerConnectsAfterTheConfiguredReconnectTimeout`, which fails with the hard-coded delay. Also run against a real OPC UA server (node-opcua) that starts listening 35 s after the client starts, with a method that answers after 5 s: | | attempts every | method call | |---|---|---| | main, component property `reconnectTimeout=2000` | 10 s | `Bad_Timeout` after 2 s, connection rebuilt | | this PR, component property `reconnectTimeout=2000` | 2 s | answered after 5 s | | this PR, endpoint option `reconnectTimeout=2000` | 2 s | answered after 5 s | | this PR, no option | 10 s | answered after 5 s | Without the new check, the endpoint option `reconnectTimeout=0` made 54,272 connection attempts, each logged as a WARN, in the 21.5 s before the server listened; with it, the endpoint is rejected at startup with `reconnectTimeout must be > 0, got: 0`. When the server was killed for 40 s after the client had connected, the option made no difference: in both runs the Milo client reconnected on its own back-off, about 16 s after the server listened again, and Camel then rebuilt the connection at once, because the restarted server no longer had the subscription. Docs: the option (generated), the sentence of the component page on retrying after a certificate failure, and the 4.24 upgrade note. #28212 (CAMEL-25692) retries refused monitored items at this interval too; whichever of the two is merged second will also update its "every 10 seconds" sentences and the description of this option. Fixes CAMEL-25873. @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]
