[ 
https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467941#comment-16467941
 ] 

Ariel Weisberg commented on CASSANDRA-10789:
--------------------------------------------

Blacklisting only on specific DCs is kind of orthogonal because you can have 
this functionality be per DC. In fact there is another ticket for the DC 
specific issue already that uses authz. It's CASSANDRA-13985

While I am underwhelmed by how this is supposed to work I don't think it not be 
persistent and or queryable introduces any technical debt. It does mean that if 
we release 4.0 without it then 4.0 will never have it which is kind of a pain. 
It seems like we are pushing the complexity of maintaining these lists to 
operational tools outside the database which are not open source or shipped 
with the database.

I don't see how it's useful to blacklist a client at just one node when it's 
going to connect to all nodes.

We should at least use a set of blacklisted hosts rather than iterating a list. 
Connection tracker should probably be updated to be a Multimap so we can look 
up the connections to kill without iterating.

> Allow DBAs to kill individual client sessions without bouncing JVM
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-10789
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10789
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Coordination
>            Reporter: Wei Deng
>            Assignee: Damien Stevenson
>            Priority: Major
>             Fix For: 4.x
>
>         Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt
>
>
> In production, there could be hundreds of clients connected to a Cassandra 
> cluster (maybe even from different applications), and if they use DataStax 
> Java Driver, each client will establish at least one TCP connection to a 
> Cassandra server (see 
> https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all 
> normal and at any given time, you can indeed see hundreds of ESTABLISHED 
> connections to port 9042 on a C* server (from netstat -na). The problem is 
> that sometimes when a C* cluster is under heavy load, when the DBA identifies 
> some client session that sends abusive amount of traffic to the C* server and 
> would like to stop it, they would like a lightweight approach rather than 
> shutting down the JVM or rolling restart the whole cluster to kill all 
> hundreds of connections in order to kill a single client session. If the DBA 
> had root privilege, they would have been able to do something at the OS 
> network level to achieve the same goal but oftentimes enterprise DBA role is 
> separate from OS sysadmin role, so the DBAs usually don't have that privilege.
> This is especially helpful when you have a multi-tenant C* cluster and you 
> want to have the impact for handling such client to be minimal to the other 
> applications. This feature (killing individual session) seems to be a common 
> feature in other databases (regardless of whether the client has some 
> reconnect logic or not). It could be implemented as a JMX MBean method and 
> exposed through nodetool to the DBAs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to