[
https://issues.apache.org/jira/browse/HBASE-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215672#comment-15215672
]
Mikhail Antonov commented on HBASE-15406:
-----------------------------------------
After re-reading comments here, it gets more and more complicated.. Look at the
review and left some comments. My concern is that it's quickly getting
complicated.
Can we avoid having a key, and have only a simple boolean lock for the state?
[~chenheng] it would really help in reviewing if you would please write up the
sequence of lock/unlocks in a simple, aborted and concurrent HBCK runs here
(and maybe add it as a javadoc to the method), we we can focus on locking
abstraction more than znode management.
> 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
>
> Attachments: HBASE-15406.patch, HBASE-15406.v1.patch,
> HBASE-15406_v1.patch, test.patch, wip.patch
>
>
> 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)
