You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stefania (JIRA)" <ji...@apache.org> on 2015/09/08 02:41:46 UTC

[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out

    [ https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734087#comment-14734087 ] 

Stefania commented on CASSANDRA-7392:
-------------------------------------

[~aweisberg] sorry for the long delay, I have finally found the time to get back to this:


* Introduced a new package {{o.a.c.db.monitoring}} where all the monitoring classes are located.
* Introduced a new interface, {{Monitorable}}, which is implemented by {{ReadCommand}} to ensure we get the CQL string only when needed, it also hosts all other required properties via {{MonitorableImpl}}: construction time, timeout and state. A {{Monitorable}} is basically an operation.
* Renamed {{OpState}} to {{MonitoringStateRef}}, which extends {{AtomicReference<MonitoringState>}}; {{MonitoringState}} is just an enum.
* Renamed {{OpMonitoring}} to {{MonitoringTask}}, which is a {{Runnable}} scheduled periodically to check a COW array of atomic references to operations. The atomic references are stored in thread local objects, {{MonitorableThreadLocal}} and their payload is updated by the clients that wish to have an operation monitored.
* Implemented aggregated logging in {{MonitoringTask}}.
* Extended utests.

I believe this should address all of the comments discussed above except for:

bq. In DroppableRunnable you switch from System.currentTimeMillis() to nanoTime(). I always looking for opportunities to avoid getting the current time (get it once and pass it around). We grab the time once when reading a message so theoretically if there has been no blocking you don't need to grab it again if we had ponies. Not sure if there is an opportunity for that here.

There is no message involved here so I don't think we can avoid grabbing the time again.

--

Please note new 3.0 branch: https://github.com/stef1927/cassandra/commits/7392-3.0

Pull request for updated dtests: https://github.com/riptano/cassandra-dtest/pull/535

CI:

http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-7392-3.0-dtest/
http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-7392-3.0-testall/

> 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)