[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241497#comment-16241497
]
Chang chen commented on HBASE-17375:
yes please, we already replaced it.
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
>Assignee: Chang chen
> Fix For: 2.0.0
>
> Attachments: HBASE_17375_master_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14178) regionserver blocks because of waiting for offsetLock
[
https://issues.apache.org/jira/browse/HBASE-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027673#comment-16027673
]
Chang chen commented on HBASE-14178:
In case of cache miss, if missed row is accessed simultaneously, then clients
have to access cache one by one. does this also block RS ?
> regionserver blocks because of waiting for offsetLock
> -
>
> Key: HBASE-14178
> URL: https://issues.apache.org/jira/browse/HBASE-14178
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.98.6
>Reporter: Heng Chen
>Assignee: Heng Chen
> Fix For: 2.0.0, 0.98.14, 1.0.2, 1.2.0, 1.1.2
>
> Attachments: HBASE-14178-0.98.patch, HBASE-14178-0.98_v8.patch,
> HBASE-14178-branch_1_v8.patch, HBASE-14178.patch, HBASE-14178_v1.patch,
> HBASE-14178_v2.patch, HBASE-14178_v3.patch, HBASE-14178_v4.patch,
> HBASE-14178_v5.patch, HBASE-14178_v6.patch, HBASE-14178_v7.patch,
> HBASE-14178_v8.patch, jstack
>
>
> My regionserver blocks, and all client rpc timeout.
> I print the regionserver's jstack, it seems a lot of threads were blocked
> for waiting offsetLock, detail infomation belows:
> PS: my table's block cache is off
> {code}
> "B.DefaultRpcServer.handler=2,queue=2,port=60020" #82 daemon prio=5 os_prio=0
> tid=0x01827000 nid=0x2cdc in Object.wait() [0x7f3831b72000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at org.apache.hadoop.hbase.util.IdLock.getLockEntry(IdLock.java:79)
> - locked <0x000773af7c18> (a
> org.apache.hadoop.hbase.util.IdLock$Entry)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:352)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.loadDataBlockWithScanInfo(HFileBlockIndex.java:253)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.seekTo(HFileReaderV2.java:524)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.reseekTo(HFileReaderV2.java:572)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseekAtOrAfter(StoreFileScanner.java:257)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:173)
> at
> org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:313)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.requestSeek(KeyValueHeap.java:269)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:695)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.seekAsDirection(StoreScanner.java:683)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:533)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:140)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:3889)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:3969)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:3847)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.next(HRegion.java:3820)
> - locked <0x0005e5c55ad0> (a
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.next(HRegion.java:3807)
> at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:4779)
> at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:4753)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.get(HRegionServer.java:2916)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29583)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2027)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - <0x0005e5c55c08> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-16594) ROW_INDEX_V2 DBE
[ https://issues.apache.org/jira/browse/HBASE-16594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15781916#comment-15781916 ] Chang chen commented on HBASE-16594: Hi Guys How does ROW_INDEX_VX encoder compare to prefix tree? Thanks Chang > ROW_INDEX_V2 DBE > > > Key: HBASE-16594 > URL: https://issues.apache.org/jira/browse/HBASE-16594 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-16594-master_v1.patch, HBASE-16594-master_v2.patch > > > See HBASE-16213, ROW_INDEX_V1 DataBlockEncoding. > ROW_INDEX_V1 is the first version which have no storage optimization, > ROW_INDEX_V2 do storage optimization: store every row only once, store column > family only once in a HFileBlock. > ROW_INDEX_V1 is : > /** > * Store cells following every row's start offset, so we can binary search to > a row's cells. > * > * Format: > * flat cells > * integer: number of rows > * integer: row0's offset > * integer: row1's offset > * > * integer: dataSize > * > */ > ROW_INDEX_V2 is : > * row1 qualifier timestamp type value tag > * qualifier timestamp type value tag > * qualifier timestamp type value tag > * row2 qualifier timestamp type value tag > * row3 qualifier timestamp type value tag > * qualifier timestamp type value tag > * > * integer: number of rows > * integer: row0's offset > * integer: row1's offset > * > * column family > * integer: dataSize -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15781871#comment-15781871
]
Chang chen commented on HBASE-17375:
Thanks for your info.
Unfortunately it's too new, so that i can't use it in prod.
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
>Assignee: Chang chen
> Fix For: 2.0.0
>
> Attachments: HBASE_17375_master_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: HBASE_17375_master_v1.patch
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Fix For: 2.0.0
>
> Attachments: HBASE_17375_master_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: (was: HBASE_17375_v1.patch)
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Fix For: 2.0.0
>
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Fix Version/s: 2.0.0
Status: Patch Available (was: Open)
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.24, 0.98.23, 1.1.7
>Reporter: Chang chen
> Fix For: 2.0.0
>
> Attachments: HBASE_17375_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: HBASE_17375_v1.patch
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Fix For: 2.0.0
>
> Attachments: HBASE_17375_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: (was: HBASE_17375_v1.patch)
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15779861#comment-15779861
]
Chang chen commented on HBASE-17375:
[~ram_krish] i uploaded a patch ,please review
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: HBASE_17375_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: HBASE_17375_v1.patch
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: HBASE_17375_v1.patch, row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15779536#comment-15779536
]
Chang chen commented on HBASE-17375:
sorry, what is the meaning of ITBLL?
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15779537#comment-15779537
]
Chang chen commented on HBASE-17375:
sorry, what is the meaning of ITBLL?
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Comment: was deleted
(was: sorry, what is the meaning of ITBLL?)
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15779498#comment-15779498
]
Chang chen commented on HBASE-17375:
oh my, I didn't see this on [http://hbase.apache.org/book.html#compression]
{quote}
Prefix Tree
Prefix tree encoding was introduced as an experimental feature in HBase 0.96.
It provides similar memory savings to the Prefix, Diff, and Fast Diff encoder,
but provides faster random access at a cost of slower encoding speed.
{quote}
We just want to use random access feature of Prefix Tree. Besides stableness
and slow encoding speed, is there other issues for Prefix tree?
Actually for stableness, I thought it should be stable, since it was introduced
3 years ago.
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15778096#comment-15778096
]
Chang chen edited comment on HBASE-17375 at 12/26/16 10:36 AM:
---
I already wrote a test case in a standalone application, I will upload a UT
patch ASAP
was (Author: baibaichen):
I already write a test case in a standalone application, I will apply a UT
patch ASAP
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15778096#comment-15778096
]
Chang chen commented on HBASE-17375:
I already write a test case in a standalone application, I will apply a UT
patch ASAP
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Description:
Recently, we find our hbase compaction thread never end. Assume we have
following cells:
{quote}
1
1
1
1
1
1
1
1
{quote}
If we encode above datas into prefix tree block, then it looks like:
!row trie example.PNG!
Assume the current row is {color:red}Abc{color} (e.g. the current row node is
4), then the previous row should be *Aa* (e.g. 2). However
previousRowInternal return {color:red}A{color}(e.g. 1)
After investigation, I believe it's the bug of
PrefixTreeArrayReversibleScanner#previousRowInternal.
{code}
private boolean previousRowInternal() {
//...
while (!beforeFirst) {
//
// what if currentRowNode is nub?
if (currentRowNode.hasOccurrences()) {// escape clause
currentRowNode.resetFanIndex();
return true;// found some values
}
}
{code}
currentRowNode.hasOccurrences() only test whether it has cell or not. But in
the case of currentRowNode.isNub() is true, previousRowInternal should follow
the previous fan instead of return.
was:
Recently, we find our hbase compaction thread never end. After investigation, I
believe it's the bug of PrefixTreeArrayReversibleScanner#previousRowInternal.
{code}
private boolean previousRowInternal() {
//...
while (!beforeFirst) {
//
// what if currentRowNode is nub?
if (currentRowNode.hasOccurrences()) {// escape clause
currentRowNode.resetFanIndex();
return true;// found some values
}
}
{code}
Assume we have following cells:
{quote}
1
1
1
1
1
1
1
1
{quote}
If the current row is {color:red}Abc{color}, then the preivous row should be
*Aa*,. However previousRowInternal return {color:red}A{color}
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. Assume we have
> following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If we encode above datas into prefix tree block, then it looks like:
> !row trie example.PNG!
> Assume the current row is {color:red}Abc{color} (e.g. the current row node is
> 4), then the previous row should be *Aa* (e.g. 2). However
> previousRowInternal return {color:red}A{color}(e.g. 1)
> After investigation, I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> currentRowNode.hasOccurrences() only test whether it has cell or not. But in
> the case of currentRowNode.isNub() is true, previousRowInternal should
> follow the previous fan instead of return.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
[
https://issues.apache.org/jira/browse/HBASE-17375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17375:
---
Attachment: row trie example.PNG
> PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
> ---
>
> Key: HBASE-17375
> URL: https://issues.apache.org/jira/browse/HBASE-17375
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.7, 0.98.23, 0.98.24
>Reporter: Chang chen
> Attachments: row trie example.PNG
>
>
> Recently, we find our hbase compaction thread never end. After investigation,
> I believe it's the bug of
> PrefixTreeArrayReversibleScanner#previousRowInternal.
> {code}
> private boolean previousRowInternal() {
> //...
> while (!beforeFirst) {
> //
> // what if currentRowNode is nub?
> if (currentRowNode.hasOccurrences()) {// escape clause
> currentRowNode.resetFanIndex();
> return true;// found some values
> }
> }
> {code}
> Assume we have following cells:
> {quote}
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> {quote}
> If the current row is {color:red}Abc{color}, then the preivous row should be
> *Aa*,. However previousRowInternal return {color:red}A{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-17375) PrefixTreeArrayReversibleScanner#previousRowInternal doesn't work correctly
Chang chen created HBASE-17375:
--
Summary: PrefixTreeArrayReversibleScanner#previousRowInternal
doesn't work correctly
Key: HBASE-17375
URL: https://issues.apache.org/jira/browse/HBASE-17375
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.24, 0.98.23, 1.1.7
Reporter: Chang chen
Recently, we find our hbase compaction thread never end. After investigation, I
believe it's the bug of PrefixTreeArrayReversibleScanner#previousRowInternal.
{code}
private boolean previousRowInternal() {
//...
while (!beforeFirst) {
//
// what if currentRowNode is nub?
if (currentRowNode.hasOccurrences()) {// escape clause
currentRowNode.resetFanIndex();
return true;// found some values
}
}
{code}
Assume we have following cells:
{quote}
1
1
1
1
1
1
1
1
{quote}
If the current row is {color:red}Abc{color}, then the preivous row should be
*Aa*,. However previousRowInternal return {color:red}A{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15744030#comment-15744030
]
Chang chen edited comment on HBASE-17295 at 12/13/16 3:37 AM:
--
The latest namespace region was created half year ago, log was already rolled.
{code}
$ hadoop fs -ls
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa
Found 3 items
-rw-r--r-- 3 hbase hbase 42 2016-02-26 12:30
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa/.regioninfo
{code}
Interesting, Master still balances these two regions, and hbck report:
{code}
ERROR: (region
hbase:namespace,,1456460815614.cb95abb94ed97849733d6a4d9c1d40aa.) Multiple
regions have the same startkey:
ERROR: (region
hbase:namespace,,1437013955376.1f6a26f3018010b3753663711e441682.) Multiple
regions have the same startkey:
ERROR: Found inconsistency in table hbase:namespace
{code}
was (Author: baibaichen):
The latest namespace region was created half year ago, log was already rolled.
{quote}
$ hadoop fs -ls
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa
Found 3 items
-rw-r--r-- 3 hbase hbase 42 2016-02-26 12:30
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa/.regioninfo
{quote}
Interesting, Master still balances these two regions, and hbck report:
{code}
ERROR: (region
hbase:namespace,,1456460815614.cb95abb94ed97849733d6a4d9c1d40aa.) Multiple
regions have the same startkey:
ERROR: (region
hbase:namespace,,1437013955376.1f6a26f3018010b3753663711e441682.) Multiple
regions have the same startkey:
ERROR: Found inconsistency in table hbase:namespace
{code}
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {code:title=HRegion#checkSplit}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> //.
> }
> {code}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15744030#comment-15744030
]
Chang chen commented on HBASE-17295:
The latest namespace region was created half year ago, log was already rolled.
{quote}
$ hadoop fs -ls
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa
Found 3 items
-rw-r--r-- 3 hbase hbase 42 2016-02-26 12:30
/hbasedata/hbase-common/data/hbase/namespace/cb95abb94ed97849733d6a4d9c1d40aa/.regioninfo
{quote}
Interesting, Master still balances these two regions, and hbck report:
{code}
ERROR: (region
hbase:namespace,,1456460815614.cb95abb94ed97849733d6a4d9c1d40aa.) Multiple
regions have the same startkey:
ERROR: (region
hbase:namespace,,1437013955376.1f6a26f3018010b3753663711e441682.) Multiple
regions have the same startkey:
ERROR: Found inconsistency in table hbase:namespace
{code}
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {code:title=HRegion#checkSplit}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> //.
> }
> {code}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17295:
---
Attachment: (was: bug.PNG)
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {code:title=HRegion#checkSplit}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> //.
> }
> {code}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17295:
---
Attachment: bug.PNG
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {code:title=HRegion#checkSplit}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> //.
> }
> {code}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17295:
---
Description:
>From the codes, hbase namespace meta table should not allowed to be split.
{code:title=HRegion#checkSplit}
public byte[] checkSplit() {
// Can't split META
if (this.getRegionInfo().isMetaTable() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
if (shouldForceSplit()) {
LOG.warn("Cannot split meta region in HBase 0.20 and above");
}
return null;
}
//.
}
{code}
But recently, I see two namespace regions in our production deployment. It
may be cased by restarting when cluster is in certain state.
was:
>From the codes, hbase namespace meta table should not allowed to be split.
{quote}
public byte[] checkSplit() {
// Can't split META
if (this.getRegionInfo().isMetaTable() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
if (shouldForceSplit()) {
LOG.warn("Cannot split meta region in HBase 0.20 and above");
}
return null;
}
{quote}
But recently, I see two namespace regions in our production deployment. It
may be cased by restarting when cluster is in certain state.
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {code:title=HRegion#checkSplit}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> //.
> }
> {code}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17295:
---
Description:
>From the codes, hbase namespace meta table should not allowed to be split.
{quote}
public byte[] checkSplit() {
// Can't split META
if (this.getRegionInfo().isMetaTable() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
if (shouldForceSplit()) {
LOG.warn("Cannot split meta region in HBase 0.20 and above");
}
return null;
}
{quote}
But recently, I see two namespace regions in our production deployment. It
may be cased by restarting when cluster is in certain state.
was:
>From the codes, hbase namespace meta table should not allowed to be split.
{quote}
public byte[] checkSplit() {
// Can't split META
if (this.getRegionInfo().isMetaTable() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
if (shouldForceSplit()) {
LOG.warn("Cannot split meta region in HBase 0.20 and above");
}
return null;
}
{quote}
But recently, I see two namespace regions in our production deployment. it
may cased by restart clusters.
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {quote}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> {quote}
> But recently, I see two namespace regions in our production deployment. It
> may be cased by restarting when cluster is in certain state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[
https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chang chen updated HBASE-17295:
---
Description:
>From the codes, hbase namespace meta table should not allowed to be split.
{quote}
public byte[] checkSplit() {
// Can't split META
if (this.getRegionInfo().isMetaTable() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
if (shouldForceSplit()) {
LOG.warn("Cannot split meta region in HBase 0.20 and above");
}
return null;
}
{quote}
But recently, I see two namespace regions in our production deployment. it
may cased by restart clusters.
> The namespace table has two regions
> ---
>
> Key: HBASE-17295
> URL: https://issues.apache.org/jira/browse/HBASE-17295
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Chang chen
> Attachments: bug.PNG
>
>
> From the codes, hbase namespace meta table should not allowed to be split.
> {quote}
> public byte[] checkSplit() {
> // Can't split META
> if (this.getRegionInfo().isMetaTable() ||
>
> TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable())) {
> if (shouldForceSplit()) {
> LOG.warn("Cannot split meta region in HBase 0.20 and above");
> }
> return null;
> }
> {quote}
> But recently, I see two namespace regions in our production deployment. it
> may cased by restart clusters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[ https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chang chen updated HBASE-17295: --- Attachment: bug.PNG see the attached pictures, you fill find that there are 2 regions with same start and end key for hbase:namesapce table > The namespace table has two regions > --- > > Key: HBASE-17295 > URL: https://issues.apache.org/jira/browse/HBASE-17295 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Chang chen > Attachments: bug.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[ https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chang chen updated HBASE-17295: --- Attachment: (was: Capture.PNG) > The namespace table has two regions > --- > > Key: HBASE-17295 > URL: https://issues.apache.org/jira/browse/HBASE-17295 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Chang chen > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17295) The namespace table has two regions
[ https://issues.apache.org/jira/browse/HBASE-17295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chang chen updated HBASE-17295: --- Attachment: Capture.PNG > The namespace table has two regions > --- > > Key: HBASE-17295 > URL: https://issues.apache.org/jira/browse/HBASE-17295 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Chang chen > Attachments: Capture.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17295) The namespace table has two regions
Chang chen created HBASE-17295: -- Summary: The namespace table has two regions Key: HBASE-17295 URL: https://issues.apache.org/jira/browse/HBASE-17295 Project: HBase Issue Type: Bug Affects Versions: 1.0.0 Reporter: Chang chen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
