fixes bug w/ deletion of compaction thread pool#3750
fixes bug w/ deletion of compaction thread pool#3750keith-turner merged 2 commits intoapache:2.1from
Conversation
Fixes a bug where a change in compaction config that deleted a compaction thread pool would leave any tablets compacting on that thread pool in a bad state. The problem was caused by shutdownNow being called on the thread pool which could cause an interrupted exception during commiting the compaction. This change allows compactions running on the thread pool to complete while canceling any compactions queued on the thread pool. fixes apache#3749
|
This change could result in over subscription of resources. For example if a thread pool A with 10 threads is replaced by thread pool B with 15 threads, then this change will let anything running on A complete and make B available for running new compaction. This could result in 25 compactions running for a brief period. This change could be improved to leverage existing compaction cancellation mechanisms (not an thread interrupt) to request the 10 compactions running on A stop their-self. Was not sure about making this change, thinking it would probably be for the best. It may waste work, but would make it easier to reason about resources. |
|
Not cancelling majc would cause Update: I looked, it doesn't. |
|
Updated to cancel running compaction in the deleted thread pool in c2fd9de. One of the tserver logs from running the new IT added in the PR looks like the following. |
|
Would it be worth providing feedback to the user that removing the compaction queue will result in cancelling running compactions? If I was changing the value it seems like I'd want to go ahead - I'm changing it for a reason. But, If I know that running compactions are cancelled on the change, I would know to resubmit any that I may have cared about? |
If a tablets need to compact then it will automatically start running on the new thread pool. Should not need to resubmit anything. |
So user compactions are not impacted? |
Fixes a bug where a change in compaction config that deleted a compaction thread pool would leave any tablets compacting on that thread pool in a bad state. The problem was caused by shutdownNow being called on the thread pool which could cause an interrupted exception during commiting the compaction.
This change allows compactions running on the thread pool to complete while canceling any compactions queued on the thread pool.
fixes #3749