[jira] [Commented] (HBASE-25709) Close region may stuck when region is compacting and skipped most cells read

["Michael Stack (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-25709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317366#comment-17317366 ] 

Michael Stack commented on HBASE-25709:
---------------------------------------

Patch looks good. Defaults to off. Why would we not just have this flag enabled always [~Xiaolin Ha]? If a Region has been asked close, compactions should be preempted and put aside until we open in new location? Close should preempt everything I'd suggest except an ongoing user read?

> Close region may stuck when region is compacting and skipped most cells read
> ----------------------------------------------------------------------------
>
>                 Key: HBASE-25709
>                 URL: https://issues.apache.org/jira/browse/HBASE-25709
>             Project: HBase
>          Issue Type: Improvement
>          Components: Compaction
>    Affects Versions: 1.4.13
>            Reporter: Xiaolin Ha
>            Assignee: Xiaolin Ha
>            Priority: Major
>         Attachments: Master-UI-RIT.png, RS-region-state.png
>
>
> We found in our cluster about stop region stuck. The region is compacting, and its store files has many TTL expired cells. Close region state marker(HRegion#writestate.writesEnabled) is not checked in compaction, because most cells were skipped. 
> !RS-region-state.png|width=698,height=310!
>  
> !Master-UI-RIT.png|width=693,height=157!
>  
> HBASE-23968 has encountered similar problem, but the solution in it is outer the method
> InternalScanner#next(List<Cell> result, ScannerContext scannerContext), which will not return if there are many skipped cells, for current compaction scanner context. As a result, we need to return in time in the next method, and then check the stop marker.
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)