[
https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791583#comment-14791583
]
Ariel Weisberg commented on CASSANDRA-7392:
-------------------------------------------
bq. I've read this documentation according to which the updated value might not
be visible to other threads until some other volatile write or synchronizing
action occurs and it occurred to me that the worker thread may carry on working
on the query even though the query has been aborted by the monitoring thread.
I'm not sure which part of the documentation you are reading. When it comes to
global visibility guarantees they are usually about ordering, not when things
will become visible in terms of wall clock time. I can't find a citation for
this, but I am sure Benedict can back me up that my understanding is correct.
Compare and set basically "locks" a cache line so the read can be performed
atomically with the store, and it blocks until the store buffer is drained (all
previous stores are finished).
lazySet is a compiler barrier that prevents reordering and on x86 not much else
because it is TSO.
Whether you use compare and set or lazy set the time to global visibility is
the same because the stores go through the store buffer the same way. CPUs
always have exclusive access to cache lines when they are writing (see MESI).
All compare and set does is hold the cache line in the exclusive state long
enough to make the comparison and store atomic. Once a store enters the store
buffer it drains as fast as it can (and this is where I am missing a citation).
The reason lazySet is necessary is that instructs the compiler to properly
order prior stores and also instructs it not to optimize away the store.
bq. So we want to log all queries or are we OK with just the first 50?
Basically is there anything else that should be done?
Sorry my mistake. What I was trying to say is that they log the full query
contents. I still think it should be limited (and that 50 is a lot). Since it's
debug and off by default I won't complain about logging 50 at time.
Without being able to aggregate the queries I think our options are basically
shotgunning out some random queries from the total set of problem queries or
logging every one and allowing people to process them offline. I opt for
picking some random queries because I don't want to roll the log if possible by
default.
> 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)
