[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643077#comment-14643077
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
Not done reviewing. Just wanted to drop a thought on design/performance. Right
now it schedules a monitoring task for every operation. This has a cost linear
to the number of operations and adds a contended queue with a not great queue
implementation (priority queue). My wild guess is that there may be a workload
we care about that will highlight this. If we do our jobs it should bottleneck
eventually as it is shared state accessed for every single operation.
What I would suggest is inverting the process. Have a thread wake up
periodically and walk the list of in progress operations looking for ones that
need to be timed out. You can store the in progress operation in a thread
local. When the thread local is created it inserts into a COW array list that
the monitoring thread can iterate. That way there is no mutation of shared
state and it only enters shared state periodically when the the monitoring
thread walks the list.
This alternative approach has a cost linear to the number of threads
dispatching tasks and almost no coherence cost.
> 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)
