[ 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org