[
https://issues.apache.org/jira/browse/CASSANDRA-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914187#action_12914187
]
Nick Bailey commented on CASSANDRA-1516:
----------------------------------------
bq. drain we can address by adding progress to CFS.flushWriter and a "drained N
out of M" method to StorageService
By adding progress do you just mean number of threads queued+active vs number
of threads scheduled? Is that enough insight or do we need to include amount
of data converted from memtables to sstables? The problem with number of
threads approach is we use a fixed size blocking queue. Once that fills up
calls to submit threads just block so we don't have an accurate view of what is
left to execute.
> Explicitly expose ongoing per-node tasks (like compactions, repair, etc) and
> est. % done
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-1516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1516
> Project: Cassandra
> Issue Type: Wish
> Components: Core
> Reporter: paul cannon
> Priority: Minor
> Fix For: 0.7.0
>
> Original Estimate: 5h
> Remaining Estimate: 5h
>
> so major compaction, read-only compaction, repair, drain, and bootstrap are
> the on-node tasks I'm pretty sure make sense to be exposed in this way.
> snapshotting might make sense too.
> some of these can be "detected" using heuristics on the number of tasks alive
> in different stages, but it would be preferable if it could be made more
> clear.
> the interface should allow multiple tasks and respective percentages to be
> ongoing at the same time, especially since some tasks (like repair)
> implicitly kick off other sub-tasks (compaction) and both of them would
> normally show up at the same time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
