[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14737572#comment-14737572
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
Sorry I am coming back with more non-test feedback. Yesterday the diff I was
reviewing was just the latest changes.
* [How does creating a monitoring state ref not stored anywhere
work?|https://github.com/apache/cassandra/compare/cassandra-3.0...stef1927:7392-3.0#diff-2e17efa5977a71330df6651d3bec0d12R381].
Is this for things that read, but aren't actually read operations? I looked up
the call chain and that appears to be the case.
* [Can you make these
properties?|https://github.com/apache/cassandra/compare/cassandra-3.0...stef1927:7392-3.0#diff-e06002c30313f8ead63ee472617d1b10R42]
I would also say that 10 milliseconds is closer to more often (of course I am
hand waving). If it's necessary to check that often for precision/timeliness
then sure. Not sure what cross node timeouts are generally set at. It will
probably be fine either way.
* [So here is a
pony.|https://github.com/apache/cassandra/compare/cassandra-3.0...stef1927:7392-3.0#diff-e06002c30313f8ead63ee472617d1b10R42]
One thing I am leery of is overly chatty relative to its utility logging and
rolling logs. Reporting on N different timed out queries every five seconds is
going to be too much and cause log rolling pushing out other relevant
statements. So the pony is to sort them by # of timeouts, only display N=5, and
aggregate them all into a single log statement. If there are more than five,
add an ellipsis indicating some were dropped, along with the #. Then add a
property allowing the maximum number to be displayed to be configured so people
can get all of them on the outside chance it is helpful.
* The next pony is backoff. In a bad situation where we have elected to report
the last time we ran, we should start reporting less frequently up to a point.
This is functionality that can be factored out usefully IMO for other kinds of
logging/reporting. And then people can have the option of turning backoff off
if it's not what they want (or load the backoff strategy by reflection). But
like I said, ponies. The important thing is to not spam the log, causing
rolling, and obscure other log info.
* Hah, sleep quietly. Yeah we need that one.
* MonitoringTask doesn't test the minor, but important case, if there are no
failed operations does it refrain from logging? So < timeout, or abort()
returns false.
* [This kind of thing should have a Thread.yield() in
it.|https://github.com/apache/cassandra/compare/cassandra-3.0...stef1927:7392-3.0#diff-f840c39b421f5df75e5e92304762bdc9R75]
We run several unit tests in parallel and if tests spin they can interfere
with other tests. Same for similar loops.
* Reduce report delay millis for test? Wall clock time spent sleeping extends
the total time that tests run. Or maybe just poke the task manually so that you
don't have to wait at all? Reducing the timeout is problematic since it leads
to false positives. If there is a way to get a free lunch with the test running
faster it would be good.
The tests were persuasive. If cassci is happy I think the tests are good.
> 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)
