[
https://issues.apache.org/jira/browse/CASSANDRA-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913075#action_12913075
]
Jeremy Hanna edited comment on CASSANDRA-1485 at 9/21/10 12:56 PM:
-------------------------------------------------------------------
bq. Could we attach the weights to the queue to minimize the work done in the
scheduling loop?
I agree that we want to minimize instructions in the scheduler. However, the
getWeight method only does a null check and potentially a hashmap lookup. If
we were to attach weights to the queue, say make the queue have a Pair<String,
Integer> key instead of just a String key, that might cause a lot more objects
(Pairs and Integers) to be created. Also, it would still have to call
getWeight. It would just call it in the queue(...) method instead of in the
schedule() loop. So getWeight would still be called the same number of times -
once per request thread.
bq. In the innermost loop, you should probably break the weighted loop if the
thread popped is ever null
true - will add that.
bq. The changes in ClientState are not necessary for this patch
They're not necessary for this patch, but it cleans up that method and removes
the necessity for SCHEDULE_ON_KEYSPACE by just doing a switch over the values
in that enum. Changing the name to SchedulingValue just seemed more intuitive
to me as I had been confusing schedulerId and schedulingId. It helped me get
them straight more easily - maybe that's just me.
was (Author: jeromatron):
bq Could we attach the weights to the queue to minimize the work done in
the scheduling loop?
I agree that we want to minimize instructions in the scheduler. However, the
getWeight method only does a null check and potentially a hashmap lookup. If
we were to attach weights to the queue, say make the queue have a Pair<String,
Integer> key instead of just a String key, that might cause a lot more objects
(Pairs and Integers) to be created. Also, it would still have to call
getWeight. It would just call it in the queue(...) method instead of in the
schedule() loop. So getWeight would still be called the same number of times -
once per request thread.
bq In the innermost loop, you should probably break the weighted loop if the
thread popped is ever null
true - will add that.
bq The changes in ClientState are not necessary for this patch
They're not necessary for this patch, but it cleans up that method and removes
the necessity for SCHEDULE_ON_KEYSPACE by just doing a switch over the values
in that enum. Changing the name to SchedulingValue just seemed more intuitive
to me as I had been confusing schedulerId and schedulingId. It helped me get
them straight more easily - maybe that's just me.
> Add a weighted request scheduler
> --------------------------------
>
> Key: CASSANDRA-1485
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1485
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.7 beta 1
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7 beta 2
>
> Attachments: 0001-added-basic-keyspace-weighting.patch
>
>
> Now that CASSANDRA-1035 has given Cassandra a request scheduler interface, it
> would be nice to have a weighted request scheduler.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
