[
https://issues.apache.org/jira/browse/CAMEL-25294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-25294.
---------------------------------
Resolution: Fixed
Fixed via https://github.com/apache/camel/pull/27325
> camel-consul - the readTimeout and writeTimeout options set the connect
> timeout of the Consul client, so the read and write timeouts cannot be
> configured
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25294
> URL: https://issues.apache.org/jira/browse/CAMEL-25294
> Project: Camel
> Issue Type: Bug
> Components: camel-consul
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> {{ConsulClientConfiguration.createConsulClient}} (used by all consul
> endpoints and by {{ConsulClusterService}}) passes the three timeouts to the
> same builder method:
> {code:java}
> if (ObjectHelper.isNotEmpty(connectTimeout)) {
> builder.withConnectTimeoutMillis(connectTimeout.toMillis());
> }
> if (ObjectHelper.isNotEmpty(readTimeout)) {
> builder.withConnectTimeoutMillis(readTimeout.toMillis()); // should be
> withReadTimeoutMillis
> }
> if (ObjectHelper.isNotEmpty(writeTimeout)) {
> builder.withConnectTimeoutMillis(writeTimeout.toMillis()); // should be
> withWriteTimeoutMillis
> }
> {code}
> So {{readTimeout}} and {{writeTimeout}} are ignored: the client always uses
> the default read and write timeouts of OkHttp (10 seconds), a request to an
> agent that does not answer always waits 10 seconds, and a longer request (a
> large value, a slow agent) always fails after 10 seconds whatever is
> configured. In addition the connect timeout is {{writeTimeout}} when it is
> set, otherwise {{readTimeout}}, otherwise {{connectTimeout}}
> ({{connectTimeout=1s&readTimeout=60s}} gives a 60 second connect timeout).
> The copy and paste dates from CAMEL-14878 (2020); until CAMEL-15520 (2022)
> the deprecated {{readTimeoutMillis}} / {{writeTimeoutMillis}} still worked.
> h3. Reproduction (unit test, no Consul)
> {{ConsulClientConfigurationTimeoutTest}}: a local {{ServerSocket}} that
> accepts connections (backlog) but never reads or answers, {{readTimeout}}
> (resp. {{writeTimeout}}) set to 200 ms, a key/value GET (resp. a PUT of a 32
> MB value): with the fix the request fails with a {{SocketTimeoutException}}
> after 200 ms; on main both tests fail with {{execution timed out after 5000
> ms}} (the client waits its default 10 seconds).
> h3. Proposed fix
> Call {{withReadTimeoutMillis}} and {{withWriteTimeoutMillis}}. Blocking
> queries ({{blockSeconds}}, the cluster view's watch) are not affected: for a
> request with a {{wait}} parameter the Consul client replaces the read timeout
> by the wait time plus {{wait/16}} plus 2 seconds ({{TimeoutInterceptor}},
> enabled by default), so {{readTimeout}} does not apply to them, before or
> after the fix. The 4.23 upgrade guide gets a short note (a request that takes
> longer than a configured {{readTimeout}} now fails, and only
> {{connectTimeout}} sets the connect timeout).
> With the fix the camel-consul unit tests pass (6).
> Affected: 4.14.x, 4.18.x and main (same code).
> Duplicate check (2026-10-03): JIRA component camel-consul (last 3 years, 6
> issues) and text "consul readTimeout" / "consul" + "timeout": none about the
> timeouts. GitHub pull requests "consul readTimeout", "consul writeTimeout",
> "ConsulClientConfiguration": none (only #2283 from 2018).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
