cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
Date Tue, 08 Sep 2015 00:41:46 GMT

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

Mime
View raw message