[jira] [Commented] (CASSANDRA-13695) ReadStage threads have no timeout

["Jason Brown (JIRA)" <ji...@apache.org>]

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

Jason Brown commented on CASSANDRA-13695:
-----------------------------------------

ftr, SASI has a QoS mechanism already [built in|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/plan/QueryController.java#L154]. The basic logic is rather straight forward, and could probably be extracted and reused. Plumbing it in/through is where the real work is, as [~cnlwsu] pointed out in the linked user@ thread. 



> ReadStage threads have no timeout
> ---------------------------------
>
>                 Key: CASSANDRA-13695
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13695
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Local Write-Read Paths
>            Reporter: Vladimir Yudovin
>
> Following this discussion: [High CPU after read timeout|https://lists.apache.org/thread.html/e22a2a77634f9228bf1d5474cc77ea461262f2e125cd2fa21a17f7a2@%3Cdev.cassandra.apache.org%3E]
> Currently ReadStage threads have no timeout and continue to run without limitation after xxx_request_timeout_in_ms expired. Thus single bad request like SELECT ... ALLOW FILTERING can paralyze the whole cluster for hours and even more.
> I guess that read request should include a kind *timeout *or *expired_at parameter* and handling thread will check it and stop processing after expiration time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org