[ https://issues.apache.org/jira/browse/HBASE-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15184252#comment-15184252 ]
Heng Chen commented on HBASE-15406: ----------------------------------- {quote} I was thinking of using Leases to keep track of the running operation (like HBCK) and if we tie a state to it (like disabling splits) then either the client will come back and remove the lease + do cleanup, or the lease will expire and the master will do the cleanup. {quote} Sounds good to me. We should extract this logic as running operation (not just hbck). I really don't like one thread to do cleanup in master just for hbck. > Split / merge switch left disabled after early termination of hbck > ------------------------------------------------------------------ > > Key: HBASE-15406 > URL: https://issues.apache.org/jira/browse/HBASE-15406 > Project: HBase > Issue Type: Bug > Reporter: Ted Yu > Priority: Critical > Fix For: 2.0.0, 1.3.0, 1.4.0 > > > This was what I did on cluster with 1.4.0-SNAPSHOT built Thursday: > Run 'hbase hbck -disableSplitAndMerge' on gateway node of the cluster > Terminate hbck early > Enter hbase shell where I observed: > {code} > hbase(main):001:0> splitormerge_enabled 'SPLIT' > false > 0 row(s) in 0.3280 seconds > hbase(main):002:0> splitormerge_enabled 'MERGE' > false > 0 row(s) in 0.0070 seconds > {code} > Expectation is that the split / merge switches should be restored to default > value after hbck exits. -- This message was sent by Atlassian JIRA (v6.3.4#6332)