Low Description
Two parts to this to help diagnose compactions issues/bottlenecks. Could be two different issues but pretty closely related.
First is adding per column family pending compactions. When theres a lot of backed up compactions but multiple ones currently being compacted its hard to identify which CF is causing the backlog. In patch provided this doesnt cover the compactions in the thread pools queue like compactionstats does but not sure how big that gets ever or if needs to be... which brings me to the second idea.
Second is to change compactionExecutor to extend the JMXEnabledThreadPoolExecutor. Big difference there would be the blocking rejection handler. With a 2^31 pending queue the blocking becoming an issue is a pretty extreme case in itself that would most likely OOM the server. So the different rejection policy shouldn't cause much of an issue but if it does can always override it to use default behavior. Would help identify scenarios where corrupted sstables or unhandled exceptions etc killing the compactions lead to a large backlog with nothing actively working. Also just for added visibility into this from tpstats.