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

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

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

I've read [this 
documentation|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6275329] 
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. This was after a couple of 
hours debugging a flacky dtest by the way, but it turns out the problem with 
the dtest was something unrelated. How can you be sure that they both become 
globally visible at the same speed? It seems to contradict with what I've read, 
do you have any other documentation source?

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

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?

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

Reply via email to