[
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
