[
https://issues.apache.org/jira/browse/CASSANDRA-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885959#action_12885959
]
Nirmal Ranganathan commented on CASSANDRA-1035:
-----------------------------------------------
The wait/notify is controlled by a counting semaphore, which essentially acts
like a blocking queue. Blocking queue would not fit this scenario, because we
are queueing requests based on a queue per user/keyspace and then round robin
thru each queue taking an element to process, or skipping if there's none. If
we had to use a blocking queue, we would need to add those items into the
queue, here the semaphore acts as a lock/count tracker.
The reason behind the constructor and initialize was, the class needs to be
class loaded during configuration, because the specific instance is provided
via configuration. I just felt starting a thread at that point would change the
purpose of the DatabaseDescriptor and hence had the initialize called in the
thrift/avro server. If its ok to go into the DatabaseDescriptor, we can move
the whole initialize section into the constructor.
> 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, 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.
