Spring WebClient, What are the drawbacks of assigning large number to max connections?

I want to create a WebClient for making a request to third party API. Today, I receive this error message

Pending acquire queue has reached its maximum size of 1000

I did a few research and found a solution to fix this problem by configuring the number of pendingAcquireMaxCount and maxConnections like this.

val sslContext = SslContextBuilder
  .forClient()
  .trustManager(InsecureTrustManagerFactory.INSTANCE)
  .build()

val connectionProvider = ConnectionProvider.builder("aws-client")
  .maxConnections(10000)
  .pendingAcquireMaxCount(-1) // no limit
  .build()

val httpConnector = HttpClient.create(connectionProvider).secure { it.sslContext(sslContext) }

return WebClient
  .builder()
  .clientConnector(ReactorClientHttpConnector(httpConnector))
  .build()

but I wonder what are the drawbacks of setting too large number of pendingAcquireMaxCount and maxConnections. Why is the default of pending acquire 1000 instead of no limit. Is there a thing that I should concern?

It seems to me that for each of the configurations you mention you have a different answer.

maxConnections

This defines the number of channels that the client creates, and it seems to me that having this set to a high number/no limit would cause 2 problems:

1. Cause increasing memory consumption, which may lead to OOM at the end of the line.
2. May cause a certain "waste" that will create new channels when it may instead wait for another connection to finish and be reused - this depends on the implementation, as mentioned in the docs here.

pendingAcquireMaxCount

Having established that unlimited connections may cause some problems, having this set to unlimited may also cause 2 problems:

1. An overflow of requests - if requests are constantly created faster than they are resolved, this will cause the amount of requests to constantly increase (instead of simply having some of them get rejected with error). Even if there is a spike of requests and not a constant higher rate, this may cause the issue to be delayed until resolve (instead of rejecting the requests straight away and returning to normal, this will instead delay until processing them all).

2. A delay to requests - if this is unlimited, you do not know how long you may have to wait (1 second? 1 minute?) since it is dependent on the amount of previous requests, where in the limited scenario you know you are waiting for a maximum of X tries, regardless of how many requests are there.