Table of Contents

Status

Current state: Under Discussion

...

Currently, we have max.connections configuration at both the broker and listener levels, which allows us to limit the maximum number of active connections on each listener and the overall broker. However, the current implementation presents a challenge in how to effectively controlling the number of SSL connections. For example, if we have a broker supporting 10,000 SSL connections with two SSL listeners, how to configure limit of each listener becomes an issue. For example, if we set the connection count to 5,000 for each listener, we cannot precisely control the total SSL connections count to be 10,000, especially if one listener is heavily used while the other has fewer connections. Furthermore，

The new configuration could work together with max.connections to control ssl and non-ssl connections. For examplem, set max.connections to 10000, max.ssl.connections to 5000, which means non-ssl connection radio is set at 5000.

...

The behavior when the SSL connection limit is reached will be similar to reaching the maximum connection limit at the broker level. It is important to note that this configuration will not affect non-SSL listeners. 

...

I propose adding an additional condition: if the number of SSL connections exceeds the SSL connection limit and the current listener is using SSL protocol, the connections may be closed.

Compatibility, Deprecation, and Migration Plan

...

No externally visible interface changes are proposed in this KIP. During normal operations, this is unlikely to result in any impact. When a large number of ssl connections are made to the broker at the same time, connections may be established slower, and the least recently used connections may be disconnected.

Test Plan

Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

...

Will be tested in org.apache.kafka.network.ConnectionQuotasTest.scala in the following cases:

• This configuration could be updated dynamically and correctly
• Hiting the limit of max.ssl.connections, new ssl connections will be blocked, while plaintext listener will not be affected.
• Removing one sasl connection should make the waiting connection to succeed
• sslConnectionCounts variables updated correctly

Rejected Alternatives

It might be argued that the existing listener-specific limit already provides satisfactory ability to limit SSL listener.

As mentioned above：

1. Unable to limit ssl connections precisely.
2. The protocol of the listener may change dynamically, and the limit of the listener also needs to be modified.