[
https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17895536#comment-17895536
]
Stefan Miklosovic commented on CASSANDRA-17812:
-----------------------------------------------
[~jmckenzie] hey, we are asked internally every now and then about backporting
this. I think this is just too valuable patch to not backport. Are you strongly
opposing that? We would do this for 4.x
> 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: [email protected]
For additional commands, e-mail: [email protected]
