[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745641#comment-14745641
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
bq. aside from logging at DEBUG level is there any other blocker? Do we still
retain logging of the top N entries or shall we log all timed out queries?
The question about logging the top N entries is how is there a top N if the CQL
statements aren't normalized? They are usually going to be unique so there is
nothing to aggregate on. I think that is a real problem if we want to print a
subset and still be informative.
bq. I'm not sure if there is anything we can do about this?
You can monitor the amount of memory pinned and bound it. For instance
normalize the CQL statements and drop or truncate the parameters if too much is
pinned. If the monitoring thread wakes up every 50 milliseconds it's pretty
reasonable for it to do that. Let's be glad we don't have to do that now.
> Abort in-progress queries that time out
> ---------------------------------------
>
> Key: CASSANDRA-7392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7392
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Stefania
> Priority: Critical
> Fix For: 3.x
>
>
> Currently we drop queries that time out before we get to them (because node
> is overloaded) but not queries that time out while being processed.
> (Particularly common for index queries on data that shouldn't be indexed.)
> Adding the latter and logging when we have to interrupt one gets us a poor
> man's "slow query log" for free.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
