[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742836#comment-14742836
]
Stefania commented on CASSANDRA-7392:
-------------------------------------
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 [~pauloricardomg] is doing for
CASSANDRA-10241 by either adding a new appender writing to _query.log_ or by
using _debug.log_. Does this sound OK?
bq. Is it just a few seconds? I would be ok with a handful of seconds.
It's 4-5 seconds on my box and 8-9 seconds on Jenkins.
bq. I think other slow query logs can include the full parameters of the query.
Maybe we want to consider logging the fully formatted CQL statement or having
that option. You can end up with a query that has a reasonable execution plan,
but the bound parameters involved make it slow. Maybe we log the query up to a
maximum size by default and people can increase it via a property.
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.
bq. For the properties, there is a constant for the "cassandra." in
DatabaseDescriptor or Config (I can't recall)
{{Config.PROPERTY_PREFIX}}, thanks.
bq. I don't quite understand what min, max, and avg are telling me? I guess
it's informative if I missed hitting the timeout at the expected time?
It's to give an indication on how timely the expiration thread is, as you
suggested in the first round of the code review.
> 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)
