Multiple web client connections created instead of utilizing existing initial connection

[pantinor]

Questions

If we set the server to a larger number of max concurrent threads like 250 streams, and only send 100 requests on the webclient, which is using a max pool size of 8, it seems that 8 connections are created instead of using the single connection for all the streams.

Version

3.9.1

Context

See reproducer

Do you have a reproducer?

A reproducer is a simple project hosted on GitHub (or another forge supporting git clone operation) that has a build file that can be executed to reproduce the issue.

Reproducers are very helpful for contributors and will likely help them fixing your bug faster.

https://github.com/pantinor/vertx.issues/blob/main/issues/src/test/java/vertx/demo/StreamsVertxOnlyTest.java

Steps to reproduce

Run the test above, note the failure on the assertion for expecting 1 connection instead of 8.

Extra

• Anything that can be relevant such as OS version, JVM version

[vietj]

I think this is the expected result, the explanation is that when the pool is queries, then it can create up to 8 connections and will do it. It cannot really speculate on the number of max connection that the server will reply with.

I don't know if we can make this better.

[vietj]

that being said, if a single connection is opened and kept in the pool then it will try to use as much as possible this connection

[pantinor]

Hi Julien, I think we are expecting that if we configure the connection pool size to greater than 1, that they would be established dynamically when needed, not at the initial start of the web client traffic, and that it would use as much as possible the first connection if and until the streams max or client multiplex limit is reached. In the case of using the default of 1 max connection pool, then another connection cannot be created and failures would occur at max limits scenario.

But, if we have more than 1 connection created initially, and the traffic is used much as possible on the primary / initial connection in the pool, this can be fine too. I havent tested if that is the case yet, but was theorizing that the implementation simply looks for an "available" connection to send the request, so it spreads the requests over the first one found that is available non deterministically. I guess this is fine too.

[pantinor]

If we have a fix on this client connection pool issue, I guess it will be forward ported to 4.0.0 as well right ?

[vietj]

yes, but I don't think this can be fixed trivially.

[pantinor]

@vietj We should expect that when setting the idle timeout to a low value like 10-15 seconds on the webclient options, that all the connections should be closed after that idle timeout period has passed with no traffic. Do you agree? I have a test that seems to show the connections are not all getting closed in the conenction pool after like 60 seconds of waiting (i set idle timeout to 5 seconds). We are using a single web client instance for the test. Thoughts ? Thanks.

[jvican]

Just chiming in here, I think that solution makes sense. Instead of synchronizing the logic that opens connections or waiting for the results of in-flight connection handshakes, we should keep the current behavior of opening N connections, where N is the number of the max pool size, but then start closing connections until we're left with only one connection to the same server address. I guess the challenging bit is making sure we can swap the connection safely without affecting the request traffic.

[vietj]

I think that if you want a single connection, then you should have a pool of a size 1, otherwise there is nothing wrong with a pool opening 5 connections if you set max size to 5 when connections are aggressively demanded

[vietj]

@pantinor if there is a bug with idle timeout it should be fixed, is that what you observed ?

[vietj]

another concern I do have with the pool is that I would like the implementation to be kind of rewritten to be non blocking (currently it requires cooperation using a single thread event-loop) where all requests would not depend on an event loop but instead use non blocking to cooperate, hence why I would like to keep the pool as simple as possible.