Expose connection pooling settings for REST Client

Description

Hi Team,

The current implementations of REST Client (both quarkus-rest-client and quarkus-rest-client-reactive) does not expose connection pooling settings.

Although there are some reasonable defaults at present, in some cases, when applications are more memory sensitive or do not make frequent HTTP calls, it won’t hurt to allow the client code to play around with connection management.

I also think that similar settings are already out there for some of the Quarkus extensions (in particular, ones related to AWS services connectivity), I saw configuration properties like this one: quarkus.dynamodb.sync-client.apache.connection-time-to-live.

A follow-up feature request from a discussion in #16991.

Implementation ideas

The basic idea is straightforward, the REST Client extension should simply expose a few more configurable properties, such as:

• connection-pool.init-strategy - an enum, which could contain values like ad-hoc or on-bootstrap which would correspond to how the conn pool is filled:
  • ad-hoc - connections are created and pooled as they are requested
  • on-bootstrap - connections are created once in bulk
• connection-pool.max-size - an integer field instructing the framework to limit the size of the underlying conn pool;
• connection-pool.min-size - a minimal amount of connections to always be present in the pool to prevent latencies of re-filling an emptied pool
• connection-pool.evict-after - a Duration field, which allows to explicitly specify how long should connections live in pool; should probably default to a null-ish value to reflect the ever alive connections.

Obviously, the verbiage and the semantics in the actual implementation may differ. The list can be cut/extended if it makes sense as well. IMHO, the key properties here are the max size and eviction controls. As I mention in the description, some AWS extensions already come with nicely-looking sets of configuration properties.

It also seems to me that this proposal will require changes to the RestClientBuilder and assorted code utilities. Also, it should somehow be brought to compliance with MP REST Client spec, as the latter now does not offer connection tailoring.

[TomasHofman]

After reading the description properly, I think we already have this partly implemented (it was implemented after this issue was created).

The configuration attributes that we already added are:

quarkus.rest-client."key".connection-ttl
quarkus.rest-client."key".connection-pool-size

and these are equivalents of the connection-pool.evict-after and connection-pool.max-size suggestions. These are IMO the two important ones, that should satisfy most use cases.

The remaining two suggestions, connection-pool.init-strategy and connection-pool.min-size are not supported be the underlying client technologies (vertx client and resteasy client), at least judging by the APIs at [1] and [2].

Most of the other available pooling related properties are specific to one client impl and not supported by the other. I would not add them unless there is specific demand.

[1] https://github.com/resteasy/Resteasy/blob/main/resteasy-client-api/src/main/java/org/jboss/resteasy/client/jaxrs/ResteasyClientBuilder.java [2] https://vertx.io/docs/apidocs/io/vertx/core/http/HttpClientOptions.html

[geoand]

Yeah I agree.

Thanks for looking into it!