[
https://issues.apache.org/jira/browse/CASSANDRA-17812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17578603#comment-17578603
]
Josh McKenzie commented on CASSANDRA-17812:
-------------------------------------------
||Item|Link||
|PR|[link|https://github.com/apache/cassandra/pull/1783]|
|JDK8
CI|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/268/workflows/dd198721-b2e5-4267-9a59-56d66ff32c3e]|
|JDK11
CI|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/268/workflows/ff32f438-5509-4bd1-ab6f-2ec10cb0a041]|
> 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
>
> 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]
