cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
Date Thu, 17 Sep 2015 07:55:46 GMT


Stefania commented on CASSANDRA-7392:

bq. I'm not sure which part of the documentation you are reading. 

The last two lines of the [first paragraph|]:

(or equivalently, might not be visible to other threads) until some other volatile write or
synchronizing action occurs).

So, if I understood you correctly, you are positive that a store-store fence (rather than
a store-load fence) is sufficient to ensue other CPUs see a changed state because of the Intel
Cache coherence protocol (MESI/MESIF)? Well I suppose the atomic reference get() is a volatile
read so that would ensure a store-load fence anyway.

I therefore reverted back to {{lazySet}}, decreased the number of entries from 50 to 30, and
picked them at random.

> Abort in-progress queries that time out
> ---------------------------------------
>                 Key: CASSANDRA-7392
>                 URL:
>             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

View raw message