[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942925#comment-14942925
]
Stefania commented on CASSANDRA-7392:
-------------------------------------
bq. It kind of seems like they should both log at the same frequency
I've changed it so that they log at the same frequency and it is indeed better
this way. However, we introduced the no spam logger to avoid polluting the main
log file whereas now we potentially log one line every 5 seconds although not
the details so it should be OK.
Than you for picking up the remaining points, they should be OK now. I
converted {{numDroppedOperations}} to an atomic log and in theory we could have
a race in {{aggregateFailedOperations()}}, after emptying the queue and before
resetting the dropped operations to zero but the only way to synchronize both
would be via a lock and I don't think it strictly matters if we incorrectly say
that there were more dropped operations in one interval rather than the next.
WDYT?
As for logging during unit tests, I've changed {{logback-test.xml}} since we
cannot change the log level at runtime, I hope that's OK. I think we have a
problem with the {{TeeingAppender}}, I could not see any log messages in the
log files, only on {{stdout}}.
> 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)
