[ https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803848#comment-17803848 ]
Andrew commented on CASSANDRA-17812: ------------------------------------ Any chance of this this being backported to 4.1 since 4.2 is no longer a release? [~jmckenzie] > Rate-limit new client connection setup to avoid overwhelming bcrypt > ------------------------------------------------------------------- > > Key: CASSANDRA-17812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17812 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Encryption > Reporter: Josh McKenzie > Assignee: Josh McKenzie > Priority: Normal > Fix For: 5.0-alpha1, 5.0 > > > A flood of reconnects can cause a ton of pain at the bcrypt phase of > validating incoming connections. While this shouldn't happen during normal > operations, we need a rate limit server side - if there's a bad client out > there (version and/or configuration) that misbehaves, a way to cap the pain > on a server is quite useful. Right now the only option is to cap the total > connections which has other issues that aren't an ideal tradeoff (inability > to connect, etc). > Moving authentication requests to a small, separate pool will prevent > starvation handling all other requests. If the authExecutor pool backs up it > may cause authentication timeouts, but the clients should back off and retry > while the rest of the system continues to make progress. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org