[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743870#comment-14743870
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
bq. I propose to log at WARN a generic message such as some CQL queries timed
out using the no spam logger to avoid polluting the main log file. Then, we log
the full details at DEBUG level and follow what Paulo Motta is doing for
CASSANDRA-10241 by either adding a new appender writing to query.log or by
using debug.log. Does this sound OK?
+1. I think this dovetails nicely with the direction we are headed.
bq. It's 4-5 seconds on my box and 8-9 seconds on Jenkins.
So worth having the protection of a minimum. I have a vague calculus in my head
for how much of my time is worth it to reduce test time. 8 seconds is worth
maybe less than a half hour.
bq. At this level in ReadCommand the query is already bound. So the only
parameter we could add is the maximum query size. I am not sure we should
truncate the statement if we are logging at DEBUG level in a separate log file.
Well since this is just read queries and read queries tend to not be ginormous
(unlike writes) I could be comfortable. To really do this right you don't want
to truncate the query you want to truncate the larger values in the query so
that the shape of the query is still visible as are the smaller values that
usually serve as keys. So out of scope, something to think about for later.
For writes, we are going to be retaining the queries past the timeout for the
logger. If someone has a memory utilization issue they can't fix it by setting
the timeout lower since the logger will still retain it and it runs on it's own
period.
Even in a separate debug log file rolling is a concern. One bad log statement
can wipe away all the other information in a failure scenario.
bq. It's to give an indication on how timely the expiration thread is, as you
suggested in the first round of the code review.
Ah, right!
> 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)
