cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
Date Wed, 09 Sep 2015 01:42:46 GMT


Ariel Weisberg commented on CASSANDRA-7392:

This looks good. After initial review I don't have much feedback other than some minor concurrency/performance

* [I don't think the check is necessary, lazySet is sufficient|]
* Don't reset MonitorableThreadLocal, that requires retrieving the threadlocal, and then storing
a value in the AR (which would be cheap if lazy set). Set the state associated with the task
to "done" and let the monitoring thread ignore it. Ideally you only have to get the threadlocal
once per request.
* When doing state transitions on the monitoring ref I don't think you need CAS. You can read
and then lazySet and there is a small chance that the logging will think something was dropped
when it wasn't. The primary functionality of shedding still works and that is always an approximation.
* MonitorableImpl could extend AtomicReference instead of composing MonitoringState. This
would leak the methods into the derived classes. I'm torn as to whether that pollution is
worth it.

> Abort in-progress queries that time out
> ---------------------------------------
>                 Key: CASSANDRA-7392
>                 URL:
>             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

View raw message