cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Jirsa (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11218) Prioritize Secondary Index rebuild
Date Fri, 28 Oct 2016 16:38:59 GMT


Jeff Jirsa commented on CASSANDRA-11218:

The refactor to break apart {{Priorities}} / {{Prioritized}} is much cleaner, thanks.

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

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:
>             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

View raw message