cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7392) Abort in-progress queries that time out
Date Wed, 16 Sep 2015 21:01:46 GMT

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

Ariel Weisberg edited comment on CASSANDRA-7392 at 9/16/15 9:00 PM:
--------------------------------------------------------------------

bq. I also prefer to re-introduce the CAS in MonitoringStateRef: if the worker thread does
not notice that the query was aborted it will carry on iterating which defeats the purpose
of aborting the queries.

Is that really an issue? It just indicates it's barely timing out. It might time out in a
subsequent iteration. Timeouts are inherently approximate. Why pay a cost on every transaction
for something that isn't usually expected to happen?

When you mean doesn't notice it was aborted, you mean it completes one of these subqueries
and then is issued the next one? It would notice while processing an individual query regardless
of CAS or lazySet. They both become globally visible at the same speed so CAS isn't going
to do better.

bq. It's also worse than this. I didn't realize that the CQL string reconstructed from ReadCommand
is really an approximation as we don't have all the information there. For example, a query
without a condition on the primary key will be split in several queries as follows:
I don't see that as much of an issue other than being confusing to the reader as to what the
user visible query it was associated with. The queries are all the same structure so if we
could aggregate we would hide this anyways.

Some other databases log every slow query so this is fine as a starting point.


was (Author: aweisberg):
bq. I also prefer to re-introduce the CAS in MonitoringStateRef: if the worker thread does
not notice that the query was aborted it will carry on iterating which defeats the purpose
of aborting the queries.

Is that really an issue? It just indicates it's barely timing out. It might time out in a
subsequent iteration. Timeouts are inherently approximate. Why pay a cost on every transaction
for something that isn't usually expected to happen?

When you mean doesn't notice it was aborted, you mean it completes one of these subqueries
and then is issued the next one? It would notice while processing an individual query regardless
of CAS or lazySet. They both become globally visible at the same speed so CAS isn't going
to do better.

bq. It's also worse than this. I didn't realize that the CQL string reconstructed from ReadCommand
is really an approximation as we don't have all the information there. For example, a query
without a condition on the primary key will be split in several queries as follows:
I don't see that as much of an issue other than being confusing to the reader as to what the
user visible query was associated with. The queries are all the same structure so if we could
aggregate we would hide this anyways.

Some other databases log every slow query so this is fine as a starting point.

> 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