[
https://issues.apache.org/jira/browse/CASSANDRA-11218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615899#comment-15615899
]
Jeff Jirsa commented on CASSANDRA-11218:
----------------------------------------
The refactor to break apart {{Priorities}} / {{Prioritized}} is much cleaner,
thanks.
{quote}
Was there any special reasoning behind making the priority fields in
PrioritizedCompactionFutureTask/PrioritizedCompactionCallable/PrioritizedCompactionWrappedRunnable
atomics rather than just final? I couldn't see how they would ever be mutated,
did I overlook something?
{quote}
I was somewhat worried about possible starvation within a type/level, where a
pathological case caused recompaction of very large files (used to happen a lot
in early DTCS), so my thought was on each compare, we could adjust
(getandincrement) the subtype priority to add an element of "how long has it
been in queue". I'm not sure if that's a real concern, so I backed out that to
reduce complexity and make it easier to reason about.
Will look at the rest this afternoon.
> Prioritize Secondary Index rebuild
> ----------------------------------
>
> Key: CASSANDRA-11218
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11218
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction
> Reporter: sankalp kohli
> Assignee: Jeff Jirsa
> Priority: Minor
>
> We have seen that secondary index rebuild get stuck behind other compaction
> during a bootstrap and other operations. This causes things to not finish. We
> should prioritize index rebuild via a separate thread pool or using a
> priority queue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
