Hi zw, As you yourself wrote in the rejected alternatives section, the existing listener-specific connection limit already lets administrators limit the number of SSL connections (assuming that one listener is SSL and another is not).
I don't understand the objection to just using that capability. You mention that "the protocol of the listener may change dynamically, and the limit of the listener also needs to be modified." But the connection limit is also dynamic, so that doesn't seem to be a problem. I didn't understand the objection that a per-listener limit doesn't allow you to "limit the ssl connections precisely" -- can you explain more? Just as a general comment, I think the biggest use-case for mixed clusters that support both PLAINTEXT and SSL is when you have replication using PLAINTEXT and external connections using SSL. In that case, it's hardly worth having a separate limit for SSL, since the number of plaintext connections is bounded, and low. But perhaps your use-case is different. Do you really think you'll have both a lot of PLAINTEXT and a lot of SSL connections? cheers, Colin On Sat, Jan 6, 2024, at 23:17, zw wrote: > Hi all, > I'd like to begin discussion on KIP-1015 which proposes to add new > configuration max.ssl.connections to limit number of ssl connections in > brokers. > KIP linkļ¼ > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1015%3A+Limit+number+of+ssl+connections+in+brokers > > > Best, > Jimmy Wang
