[
https://issues.apache.org/jira/browse/CASSANDRA-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886052#action_12886052
]
Nirmal Ranganathan commented on CASSANDRA-1035:
-----------------------------------------------
The taskcount is still needed. That's what sets the throttling. We won't be
able to do that using the syncqueue. Because of the multiple queues per
user/keyspace.
Ex: Keyspace A may have incoming requests and B may not have any, in that case
if we block on the syncqueue, it would block on B and not be able to process
A's requests, until a B request arrives.
More over when there's a flood of requests, the taskcount blocks until a
release is called, whereas the syncqueue would just process everything. Note
however, this won't be effective for async requests. But either way, it
throttles the incoming requests.
Also the RR is kinda fair RR in the sense of, 100 requests for A (throttle at
say 40) wouldn't necessarily block a request from B, assuming all the requests
arrive simultaneously.
The queuesize was added to avoid a busy wait scenario, when there are no
requests.
> Implement User/Keyspace throughput Scheduler
> --------------------------------------------
>
> Key: CASSANDRA-1035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1035
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.7
> Reporter: Stu Hood
> Assignee: Nirmal Ranganathan
> Fix For: 0.7
>
> Attachments:
> 0001-Adding-the-RequestScheduler-abstraction-and-a-simple.patch,
> 0002-Thrift-related-changes-for-RequestScheduler-added-a-.patch,
> 0003-Avro-related-changes-for-RequestScheduler.patch,
> 0004-Test-case-for-RoundRobinScheduler.patch,
> 0005-Add-options-for-throttling.patch, 1035-v2.txt, 1035-v3.patch,
> 1035-v4.txt, Cassandra-1035.patch
>
>
> To support multiple applications on top of a single Cassandra cluster (and to
> protect against badly behaving clients) having a very simple scheduler for
> client operations would be very beneficial.
> Since all tasks are short lived, a sufficient scheduler would probably only
> need to manage the queue of incoming requests, and weight them based on an
> assigned ID. The ID could be dynamically determined by using ip, userid or
> keyspace for instance, and then each Runnable would be assigned an ID.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
