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, 28 Jul 2015 01:08:05 GMT

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

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

Ariel, thank you for your comments, which are quite valid and I plan on tackling as soon as
I have wrapped up two other tickets.

The core issue is how to monitor tasks. The existing approach should have a cost linear to
the number of _in progress_ operations, since we cancel the future when the operation completes.
This should be the same as the number of threads. I thought about a single thread with a queue
as well, but opted for scheduling a task per operation due to the cost of keeping a shared
array or queue. It did not occur to me to consider using a thread local, which is an excellent
idea.

To make sure I understand your suggestion correctly: an entry is inserted when the _thread
local is created_, meaning when the thread local initial value is created, so the COW array
is copied once per thread. Then, when a new operation starts, we need to atomically modify
the state in the thread local. Correct? So, this gets rid of the priority queue contention
as well as the insert and remove logarithmic costs, which is nice. The downside is the complexity
of atomically swapping in a new operation, which shouldn't be much.   

bq. Just to validate my understanding, when a query is aborted it either sends no response
or sends an error response? I just want to be sure that it doesn't silently claim there is
no more data.

It should send no response, this is the same behavior for queries that are dropped before
they are started, see the top of {{MessagingDeliveryTask.run()}}. We could also send a timeout
error but I think the coordinator times out anyway on its own, and I prefer not to change
the coordinator code.


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