You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ben Bromhead (JIRA)" <ji...@apache.org> on 2018/05/08 15:16:00 UTC
[jira] [Comment Edited] (CASSANDRA-10789) Allow DBAs to kill
individual client sessions without bouncing JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467541#comment-16467541 ]
Ben Bromhead edited comment on CASSANDRA-10789 at 5/8/18 3:15 PM:
------------------------------------------------------------------
[~aweisberg] - Given we allow per node management of non-persistent settings via nodetool (e.g. compactionthroughput etc) and we might not want to blacklist clients on all nodes (e.g. only specific DCs) I think doing this at a per node level makes sense.
If it becomes a burden for an operations perspective, then we can improve on the underlying work? I'd love to see this land without having to wait on an underlying in Cassandra coordination mechanism.
[~spodxx@gmail.com] - Throttling and connection limiting solves a different problem.
* Throttling/Limiting = I want to enforce good behavior on my clients.
* Blocking = I don't want a client to connect to this node, no matter how well behaved it is.
was (Author: benbromhead):
[~aweisberg]
Given we allow per node management of non-persistent settings via nodetool (e.g. compactionthroughput etc) and we might not want to blacklist clients on all nodes (e.g. only specific DCs) I think doing this at a per node level makes sense.
If it becomes a burden for an operations perspective, then we can improve on the underlying work.
[~spodxx@gmail.com] - Throttling and connection limiting solves a different problem.
* Throttling/Limiting = I want to enforce good behavior on my clients.
* Blocking = I don't want a client to connect to this node, no matter how well behaved it is.
> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org