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