[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14944284#comment-14944284
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
bq. 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?
I agree it's fine.
bq. 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.
You are right it is dropping log output pretty badly in the test configuration.
In the production configuration it would drop less, but still doesn't have a
working shutdown hook.
I dug a lot and finally got it to work by using the status listener to find out
when file appenders are created, cache them, then stop them on shutdown. I
think this is a problem for Paulo's work as well because this means the async
appender won't be stopped. I created CASSANDRA-10447 for it.
So you set the filter in the logging to be more permissive, but only have the
monitoring logger running at debug? The other loggers won't emit debug
statements? That sounds fine.
It looks like the NanoTimeToCurrentTimeMillis test can't check the condition it
was checking before which was that it kinda sort of work to try and propagate
NTP updates. You could have the test submit the update task to the STPE instead
of notifying it. That could be a function in NanoTimeToCurrentTimeMillis so the
details aren't foisted onto the test.
> 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)
