[BUG][JAVA][apache-httpclient] setConnectTimeout()/getConnectTimeout() have no effect — connectionTimeout field is never applied to the HttpClient

[treaz]

Bug Report

Description

For the Java client generator with library=apache-httpclient, ApiClient.setConnectTimeout(int) silently does nothing. It stores the value into a connectionTimeout field, but that field is never read anywhere else in the generated class — it's never used to build a RequestConfig/ConnectionConfig, and it's never applied to the already-constructed CloseableHttpClient.

This means any consumer who calls apiClient.setConnectTimeout(600) expecting a 600ms connect timeout gets no timeout enforcement at all — the client silently falls back to whatever HttpClients.createDefault() uses internally (Apache HttpClient5's own default connect timeout, currently 3 minutes, with no response/socket timeout at all).

openapi-generator version

7.14.0 (confirmed the same dead code still exists on master as of this report, in modules/openapi-generator/src/main/resources/Java/libraries/apache-httpclient/ApiClient.mustache)

generator config

<generatorName>java</generatorName>
<configOptions>
  <library>apache-httpclient</library>
  ...
</configOptions>

Root cause

In the generated ApiClient.java:

public ApiClient() {
  this(HttpClients.createDefault());   // httpClient built immediately, with Apache defaults
}
...
protected int connectionTimeout = 0;
...
public ApiClient setConnectTimeout(int connectionTimeout) {
  this.connectionTimeout = connectionTimeout;   // stored, never read again
  return this;
}

Grepping the whole generated file for connectionTimeout shows it's only referenced by the field declaration, the getter, and the setter — never in the request-building/execution path (ClassicRequestBuilder, HttpClientContext, or the httpClient.execute(...) call), and never used to construct a RequestConfig or ConnectionConfig that gets attached to the httpClient.

Expected behavior

Calling setConnectTimeout(ms) should actually bound the TCP connect time for subsequent requests, consistent with how the setter behaves for the other Java libraries:

• okhttp-gson: httpClient = httpClient.newBuilder().connectTimeout(ms, TimeUnit.MILLISECONDS).build(); — rebuilds the client with the timeout applied.
• native (java.net.http): this.builder.connectTimeout(connectTimeout); — applied directly to the HttpClient.Builder.

Only apache-httpclient has a setter that looks functional (matching method signature/Javadoc) but is actually a no-op.

Suggested fix

In ApiClient.mustache for apache-httpclient, wire connectionTimeout (and ideally add symmetric support for response/socket timeout, which also has no default) into a PoolingHttpClientConnectionManager + ConnectionConfig/RequestConfig, and rebuild httpClient when setConnectTimeout is called — mirroring the approach used in the okhttp-gson template.

Impact

Anyone relying on apache-httpclient's setConnectTimeout() for production timeout/resiliency behavior gets unbounded (3-minute connect / infinite response) timeouts instead.

[wing328]

mirroring the approach used in the okhttp-gson template.

can you please file a PR with the suggested fix when you've time?

[wipheg]

Hi @treaz and @wing328,

I’d be happy to work on this fix and submit a PR. Before I start, could you please let me know whether @treaz is already planning to work on it?

If not, I can update the Apache HttpClient ApiClient.mustache template so that setConnectTimeout() actually applies the configured timeout, and add a regression test to verify the behavior.

Of course, if @treaz is already working on a PR, I’ll step back to avoid duplicating the effort.