[
https://issues.apache.org/jira/browse/CASSANDRA-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862387#action_12862387
]
Stu Hood commented on CASSANDRA-1035:
-------------------------------------
Throttling on the coordinator makes a lot more sense, good point.
I began exploring plugging in alternative ThreadPools in Thrift and Avro, but
making the implementation consistent and trying to avoid patches to those
projects is enough reason to drop that idea.
Instead, how about converting StorageProxy into a non-static class, and pooling
StorageProxies? To get a StorageProxy, you would check one out from an
"IRequestScheduler" (name tbd). Since StorageProxy is stateless, the default
impl of IRS could always return the same StorageProxy, without any queueing. An
alternative IRS could implement the weighted scheduling described above.
Thoughts?
> Implement User/Keyspace throughput Scheduler
> --------------------------------------------
>
> Key: CASSANDRA-1035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1035
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Stu Hood
>
> To support multiple applications on top of a single Cassandra cluster (and to
> protect against badly behaving clients) having a very simple scheduler for
> MUTATION-STAGE and READ-STAGE 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.
