cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nirmal Ranganathan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1035) Implement User/Keyspace throughput Scheduler
Date Wed, 23 Jun 2010 21:37:51 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881897#action_12881897
] 

Nirmal Ranganathan commented on CASSANDRA-1035:
-----------------------------------------------

Having researched all the options, the only viable ones seem to be able to schedule based
on keyspace. User scheduling can happen, but requires some change with the Auth API/classes.
Just providers to get the username per se. 

There would be a configuration option to schedule based on user/keyspace/none (this would
be the identifier) 

Open Question: 
1 - Scheduler returns TimedOutException if no available tokens for user/keyspace (considering
a token based approach) 
2 - Scheduler blocks thread/request until a token is available and services the request or
times out whichever happens first. 

Since we don't control the threads/thread-scheduling, the scheduler will have to maintain
some sort of bucketing system and perform wait/notify, for a round-robin approach. Ideas welcome.


Since this is node based, there's nothing stopping a client from hitting up another controller
node and the request being re-routed back to the initial node if that has the data. CASSANDRA-685
would solve that, but I'm not sure of it's status.

> 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
>             Fix For: 0.7
>
>
> 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.


Mime
View raw message