date:20150203


[ 
https://issues.apache.org/jira/browse/HBASE-12964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304635#comment-14304635
 ] 

Hudson commented on HBASE-12964:


SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #790 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/790/])
HBASE-12964 Add the ability for hbase-daemon.sh to start in the foreground 
(eclark: rev c1a776293c81e10ff834f80d466728346b8b0fc9)
* bin/hbase-daemon.sh


 Add the ability for hbase-daemon.sh to start in the foreground
 --

 Key: HBASE-12964
 URL: https://issues.apache.org/jira/browse/HBASE-12964
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 0.98.10
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0, 0.98.11

 Attachments: HBASE-12964-v1.patch, HBASE-12964-v2.patch, 
 HBASE-12964.patch


 The znode cleaner is awesome and gives great benefits.
 As more and more deployments start using containers some of them will want to 
 run things in the foreground. hbase-daemon.sh should allow that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


[ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304652#comment-14304652
 ] 

Hudson commented on HBASE-12957:


FAILURE: Integrated in HBase-TRUNK #6084 (See 
[https://builds.apache.org/job/HBase-TRUNK/6084/])
HBASE-12957 region_mover#isSuccessfulScan may be extremely slow on region with 
lots of expired data (Hongyu Bi) (tedyu: rev 
4388fed83028325cfe75fc0a8787183db2a58855)
* bin/region_mover.rb
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerHostname.java


 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


 [ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu reassigned HBASE-12957:
--

Assignee: hongyu bi

 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12964) Add the ability for hbase-daemon.sh to start in the foreground


[ 
https://issues.apache.org/jira/browse/HBASE-12964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304569#comment-14304569
 ] 

Hudson commented on HBASE-12964:


SUCCESS: Integrated in HBase-0.98 #833 (See 
[https://builds.apache.org/job/HBase-0.98/833/])
HBASE-12964 Add the ability for hbase-daemon.sh to start in the foreground 
(eclark: rev c1a776293c81e10ff834f80d466728346b8b0fc9)
* bin/hbase-daemon.sh


 Add the ability for hbase-daemon.sh to start in the foreground
 --

 Key: HBASE-12964
 URL: https://issues.apache.org/jira/browse/HBASE-12964
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 0.98.10
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0, 0.98.11

 Attachments: HBASE-12964-v1.patch, HBASE-12964-v2.patch, 
 HBASE-12964.patch


 The znode cleaner is awesome and gives great benefits.
 As more and more deployments start using containers some of them will want to 
 run things in the foreground. hbase-daemon.sh should allow that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12959) Compact never end when table's dataBlockEncoding using PREFIX_TREE

2015-02-03 Thread wuchengzhi (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304659#comment-14304659
 ] 

wuchengzhi commented on HBASE-12959:


Not yet,please help to fix it,thanks.

  Compact never end when table's dataBlockEncoding using  PREFIX_TREE
 

 Key: HBASE-12959
 URL: https://issues.apache.org/jira/browse/HBASE-12959
 Project: HBase
  Issue Type: Bug
  Components: hbase
Affects Versions: 0.98.7
 Environment: hbase 0.98.7
 hadoop 2.5.1
Reporter: wuchengzhi
Priority: Critical
 Attachments: PrefixTreeCompact.java, txtfile-part1.txt.gz, 
 txtfile-part2.txt.gz, txtfile-part4.txt.gz, txtfile-part5.txt.gz, 
 txtfile-part6.txt.gz, txtfile-part7.txt.gz


 I upgraded the hbase from 0.96.1.1 to 0.98.7 and hadoop from 2.2.0 to 
 2.5.1,some table encoding using prefix-tree was abnormal for compacting,  the 
 gui shows the table's Compaction status is MAJOR_AND_MINOR(MAJOR) all the 
 time.
 in the regionserver dump , there are some logs as below:
 Tasks:
 ===
 Task: Compacting info in 
 PREFIX_NOT_COMPACT,,1421954285670.41ef60e2c221772626e141d5080296c5.
 Status: RUNNING:Compacting store info
 Running for 1097s  (on the  site running more than 3 days)
 
 Thread 197 (regionserver60020-smallCompactions-1421954341530):
   State: RUNNABLE
   Blocked count: 7
   Waited count: 3
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.followFan(PrefixTreeArrayScanner.java:329)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:149)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.seekForwardToOrAfter(PrefixTreeArraySearcher.java:183)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToOrBeforeUsingPositionAtOrAfter(PrefixTreeSeeker.java:199)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToKeyInBlock(PrefixTreeSeeker.java:162)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$EncodedScannerV2.loadBlockAndSeekToKey(HFileReaderV2.java:1172)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.reseekTo(HFileReaderV2.java:573)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseekAtOrAfter(StoreFileScanner.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:173)
 
 org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:313)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.reseek(KeyValueHeap.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:697)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.seekAsDirection(StoreScanner.java:683)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:533)
 
 org.apache.hadoop.hbase.regionserver.compactions.Compactor.performCompaction(Compactor.java:222)
 
 org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:77)
 
 org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:110)
 org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1099)
 org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1482)
 Thread 177 (regionserver60020-smallCompactions-1421954314809):
   State: RUNNABLE
   Blocked count: 40
   Waited count: 60
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.column.ColumnReader.populateBuffer(ColumnReader.java:81)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateQualifier(PrefixTreeArrayScanner.java:471)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateNonRowFields(PrefixTreeArrayScanner.java:452)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.nextRow(PrefixTreeArrayScanner.java:226)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.advance(PrefixTreeArrayScanner.java:208)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtQualifierTimestamp(PrefixTreeArraySearcher.java:244)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:123)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.seekForwardToOrAfter(PrefixTreeArraySearcher.java:183)

[jira] [Commented] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data

2015-02-03 Thread Hadoop QA (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304614#comment-14304614
]

Hadoop QA commented on HBASE-12957:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12696108/HBASE-12957-v0.patch
against master branch at commit 5c1b08c5ca18a499c0a336e5ebd7c6bcc45a9fad.
ATTACHMENT ID: 12696108

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:red}-1 core tests{color}. The patch failed these unit tests:

org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//artifact/patchprocess/checkstyle-aggregate.html

Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12685//console

This message is automatically generated.

region_mover#isSuccessfulScan may be extremely slow on region with lots of
expired data
---

Key: HBASE-12957
URL: https://issues.apache.org/jira/browse/HBASE-12957
Project: HBase
Issue Type: Improvement
Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
Fix For: 2.0.0, 1.1.0

Attachments: HBASE-12957-v0.patch

region_mover will call isSuccessfulScan when region has moved to make sure
it's healthy, however , if the moved region has lots of expired data
region_mover#isSuccessfulScan will take a long time to finish ,that may even
exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve
faster response in that case.
workaround:before graceful_stop/rolling_restart ，call major_compact on the
table with small TTL

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12959) Compact never end when table's dataBlockEncoding using PREFIX_TREE


[ 
https://issues.apache.org/jira/browse/HBASE-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304644#comment-14304644
 ] 

ramkrishna.s.vasudevan commented on HBASE-12959:


Okie, are you working on a patch for this?  If not I can take it up?

  Compact never end when table's dataBlockEncoding using  PREFIX_TREE
 

 Key: HBASE-12959
 URL: https://issues.apache.org/jira/browse/HBASE-12959
 Project: HBase
  Issue Type: Bug
  Components: hbase
Affects Versions: 0.98.7
 Environment: hbase 0.98.7
 hadoop 2.5.1
Reporter: wuchengzhi
Priority: Critical
 Attachments: PrefixTreeCompact.java, txtfile-part1.txt.gz, 
 txtfile-part2.txt.gz, txtfile-part4.txt.gz, txtfile-part5.txt.gz, 
 txtfile-part6.txt.gz, txtfile-part7.txt.gz


 I upgraded the hbase from 0.96.1.1 to 0.98.7 and hadoop from 2.2.0 to 
 2.5.1,some table encoding using prefix-tree was abnormal for compacting,  the 
 gui shows the table's Compaction status is MAJOR_AND_MINOR(MAJOR) all the 
 time.
 in the regionserver dump , there are some logs as below:
 Tasks:
 ===
 Task: Compacting info in 
 PREFIX_NOT_COMPACT,,1421954285670.41ef60e2c221772626e141d5080296c5.
 Status: RUNNING:Compacting store info
 Running for 1097s  (on the  site running more than 3 days)
 
 Thread 197 (regionserver60020-smallCompactions-1421954341530):
   State: RUNNABLE
   Blocked count: 7
   Waited count: 3
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.followFan(PrefixTreeArrayScanner.java:329)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:149)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.seekForwardToOrAfter(PrefixTreeArraySearcher.java:183)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToOrBeforeUsingPositionAtOrAfter(PrefixTreeSeeker.java:199)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToKeyInBlock(PrefixTreeSeeker.java:162)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$EncodedScannerV2.loadBlockAndSeekToKey(HFileReaderV2.java:1172)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.reseekTo(HFileReaderV2.java:573)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseekAtOrAfter(StoreFileScanner.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:173)
 
 org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:313)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.reseek(KeyValueHeap.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:697)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.seekAsDirection(StoreScanner.java:683)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:533)
 
 org.apache.hadoop.hbase.regionserver.compactions.Compactor.performCompaction(Compactor.java:222)
 
 org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:77)
 
 org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:110)
 org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1099)
 org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1482)
 Thread 177 (regionserver60020-smallCompactions-1421954314809):
   State: RUNNABLE
   Blocked count: 40
   Waited count: 60
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.column.ColumnReader.populateBuffer(ColumnReader.java:81)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateQualifier(PrefixTreeArrayScanner.java:471)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateNonRowFields(PrefixTreeArrayScanner.java:452)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.nextRow(PrefixTreeArrayScanner.java:226)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.advance(PrefixTreeArrayScanner.java:208)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtQualifierTimestamp(PrefixTreeArraySearcher.java:244)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:123)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.seekForwardToOrAfter(PrefixTreeArraySearcher.java:183)

[jira] [Commented] (HBASE-12914) Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade section

[
https://issues.apache.org/jira/browse/HBASE-12914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304646#comment-14304646
]

ramkrishna.s.vasudevan commented on HBASE-12914:

[~ndimiduk]
Thanks for looking into the RB. I think as per the discussions over the other
JIRA as 0.98 was considering TAgs as experimental better to notify the APIs and
related features as Unstable. I think marking Unstable is fine with me.
What others think here?

Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade
section
---

Key: HBASE-12914
URL: https://issues.apache.org/jira/browse/HBASE-12914
Project: HBase
Issue Type: Bug
Components: API, documentation
Affects Versions: 0.98.6, 0.98.7, 0.98.8, 0.98.9
Reporter: Sean Busbey
Assignee: ramkrishna.s.vasudevan
Priority: Critical
Fix For: 0.98.11

Attachments: HBASE-12914-0.98.patch, HBASE-12914-branch-1.patch,
HBASE-12914.patch

There are several features in 0.98 that require enabling HFilev3 support.
Some of those features include new extendable components that are marked
IA.Public.
Current practice has been to treat these features as experimental. This has
included pushing non-compatible changes to branch-1 as the API got worked out
through use in 0.98.
* Update all of the IA.Public classes involved to make sure they are
IS.Unstable in 0.98.
* Update the ref guide section on upgrading from 0.98 - 1.0 to make folks
aware of these changes.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12962) TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531


[ 
https://issues.apache.org/jira/browse/HBASE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304645#comment-14304645
 ] 

ramkrishna.s.vasudevan commented on HBASE-12962:


The failed tests 
{code}
org.apache.jena.hadoop.rdf.io.input.AbstractNodeTupleInputFormatTests.testMultipleInputs(AbstractNodeTupleInputFormatTests.java:477)
at 
org.apache.hadoop.hbase.coprocessor.TestMasterObserver.testRegionTransitionOperations(TestMasterObserver.java:1604)
{code}
seems unrelated.  Thanks for the reviews. Will commit it now.

 TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531
 -

 Key: HBASE-12962
 URL: https://issues.apache.org/jira/browse/HBASE-12962
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 1.0.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Attachments: HBASE-12962.patch


 Accidentally during HBASE-10531 the test case testBlockIndex() in 
 TestHFileBlockIndex was commented out.  Apologies for that. Not sure how that 
 happened. This patch uncomments the commented out test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


 [ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-12957:
---
Summary: region_mover#isSuccessfulScan may be extremely slow on region with 
lots of expired data  (was: region_mover#isSuccessfulScan may extremely slow on 
region with lots of expired data)

 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Priority: Minor
 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12962) TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531


 [ 
https://issues.apache.org/jira/browse/HBASE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-12962:
---
   Resolution: Fixed
Fix Version/s: 1.0.1
   2.0.0
   1.0.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

Pushed to master, branch-1 and branch-1.0.  0.98 does not have this problem.  
Thanks for all the reviews.

 TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531
 -

 Key: HBASE-12962
 URL: https://issues.apache.org/jira/browse/HBASE-12962
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 1.0.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 1.0.0, 2.0.0, 1.0.1

 Attachments: HBASE-12962.patch


 Accidentally during HBASE-10531 the test case testBlockIndex() in 
 TestHFileBlockIndex was commented out.  Apologies for that. Not sure how that 
 happened. This patch uncomments the commented out test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12962) TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531


 [ 
https://issues.apache.org/jira/browse/HBASE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-12962:
---
Component/s: test

 TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531
 -

 Key: HBASE-12962
 URL: https://issues.apache.org/jira/browse/HBASE-12962
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.0.0, 2.0.0, 1.0.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 1.0.0, 2.0.0, 1.0.1

 Attachments: HBASE-12962.patch


 Accidentally during HBASE-10531 the test case testBlockIndex() in 
 TestHFileBlockIndex was commented out.  Apologies for that. Not sure how that 
 happened. This patch uncomments the commented out test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12914) Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade section

2015-02-03 Thread Sean Busbey (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304695#comment-14304695
]

Sean Busbey commented on HBASE-12914:
-

I don't think we need a special InterfaceAudience setting. AFAICT, most of
these APIs are settled enough in 1.0+ for how they're labeled. The goal here
was just to make sure early adopters on the 0.98 line had a heads-up
appropriate for how we've been handling changes.

Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade
section
---

Attachments: HBASE-12914-0.98.patch, HBASE-12914-branch-1.patch,
HBASE-12914.patch

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (HBASE-12948) Increment#addColumn on the same column multi times produce wrong result

2015-02-03 Thread hongyu bi (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

hongyu bi reassigned HBASE-12948:
-

Assignee: hongyu bi

 Increment#addColumn on the same column multi times produce wrong result 
 

 Key: HBASE-12948
 URL: https://issues.apache.org/jira/browse/HBASE-12948
 Project: HBase
  Issue Type: Bug
  Components: Client, regionserver
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Critical
 Attachments: 12948-v2.patch, 12948-v3.patch, 
 HBASE-12948-0.99.2-v1.patch, HBASE-12948-v0.patch, HBASE-12948.patch


 Case:
 Initially get('row1'):
 rowkey=row1 value=1
 run:
 Increment increment = new Increment(Bytes.toBytes(row1));
 for (int i = 0; i  N; i++) {
 increment.addColumn(Bytes.toBytes(cf), Bytes.toBytes(c), 1)
 }
 hobi.increment(increment);
 get('row1'):
 if N=1 then result is 2 else if N1 the result will always be 1
 Cause:
 https://issues.apache.org/jira/browse/HBASE-7114 let increment extent 
 mutation which change familyMap from NavigableMap to List, so from client 
 side, we can buffer many edits on the same column；
 However, HRegion#increment use idx to iterate the get's results, here 
 results.sizefamily.value().size if N1，so the latter edits on the same 
 column won't match the condition {idx  results.size()  
 CellUtil.matchingQualifier(results.get(idx), kv) }, meantime the edits share 
 the same mvccVersion ,so this case happen.
 Fix:
 according to the put/delete#add on the same column behaviour ,
 fix from server side: process last edit wins on the same column inside 
 HRegion#increment to maintenance  HBASE-7114's extension and keep the same 
 result from 0.94.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


[ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304677#comment-14304677
 ] 

Hudson commented on HBASE-12957:


SUCCESS: Integrated in HBase-1.1 #138 (See 
[https://builds.apache.org/job/HBase-1.1/138/])
HBASE-12957 region_mover#isSuccessfulScan may be extremely slow on region with 
lots of expired data (Hongyu Bi) (tedyu: rev 
118f738d7ccb3f5f0c3e724bb67183e0440c201d)
* bin/region_mover.rb


 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


 [ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-12957:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12957) region_mover#isSuccessfulScan may extremely slow on region with lots of expired data


 [ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-12957:
---
Status: Patch Available  (was: Open)

 region_mover#isSuccessfulScan may extremely slow on region with lots of 
 expired data
 

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Priority: Minor
 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


 [ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-12957:
---
Fix Version/s: 1.1.0
   2.0.0

 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12948) Increment#addColumn on the same column multi times produce wrong result

2015-02-03 Thread hongyu bi (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

hongyu bi updated HBASE-12948:
--
Attachment: (was: 12948-v3.patch)

 Increment#addColumn on the same column multi times produce wrong result 
 

 Key: HBASE-12948
 URL: https://issues.apache.org/jira/browse/HBASE-12948
 Project: HBase
  Issue Type: Bug
  Components: Client, regionserver
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Critical
 Attachments: 12948-v2.patch, HBASE-12948-0.99.2-v1.patch, 
 HBASE-12948-v0.patch, HBASE-12948.patch


 Case:
 Initially get('row1'):
 rowkey=row1 value=1
 run:
 Increment increment = new Increment(Bytes.toBytes(row1));
 for (int i = 0; i  N; i++) {
 increment.addColumn(Bytes.toBytes(cf), Bytes.toBytes(c), 1)
 }
 hobi.increment(increment);
 get('row1'):
 if N=1 then result is 2 else if N1 the result will always be 1
 Cause:
 https://issues.apache.org/jira/browse/HBASE-7114 let increment extent 
 mutation which change familyMap from NavigableMap to List, so from client 
 side, we can buffer many edits on the same column；
 However, HRegion#increment use idx to iterate the get's results, here 
 results.sizefamily.value().size if N1，so the latter edits on the same 
 column won't match the condition {idx  results.size()  
 CellUtil.matchingQualifier(results.get(idx), kv) }, meantime the edits share 
 the same mvccVersion ,so this case happen.
 Fix:
 according to the put/delete#add on the same column behaviour ,
 fix from server side: process last edit wins on the same column inside 
 HRegion#increment to maintenance  HBASE-7114's extension and keep the same 
 result from 0.94.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


[ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304623#comment-14304623
 ] 

Ted Yu commented on HBASE-12957:


Ran test in hbase-shell module - pass.

Thanks for the patch, hongyu.

Thanks for the review, Stack

 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12962) TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531


[ 
https://issues.apache.org/jira/browse/HBASE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304756#comment-14304756
 ] 

Hudson commented on HBASE-12962:


SUCCESS: Integrated in HBase-1.1 #139 (See 
[https://builds.apache.org/job/HBase-1.1/139/])
HBASE-12962 - TestHFileBlockIndex.testBlockIndex() commented out during 
(ramkrishna: rev d33bc0c8c6e1b06a18837903488e3652b1c10217)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java


 TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531
 -

 Key: HBASE-12962
 URL: https://issues.apache.org/jira/browse/HBASE-12962
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.0.0, 2.0.0, 1.0.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 1.0.0, 2.0.0, 1.0.1

 Attachments: HBASE-12962.patch


 Accidentally during HBASE-10531 the test case testBlockIndex() in 
 TestHFileBlockIndex was commented out.  Apologies for that. Not sure how that 
 happened. This patch uncomments the commented out test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-12914) Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade section


 [ 
https://issues.apache.org/jira/browse/HBASE-12914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-12914:
---
Status: Patch Available  (was: Open)

 Mark public features that require HFilev3 Unstable in 0.98, warn in upgrade 
 section
 ---

 Key: HBASE-12914
 URL: https://issues.apache.org/jira/browse/HBASE-12914
 Project: HBase
  Issue Type: Bug
  Components: API, documentation
Affects Versions: 0.98.9, 0.98.8, 0.98.7, 0.98.6
Reporter: Sean Busbey
Assignee: ramkrishna.s.vasudevan
Priority: Critical
 Fix For: 0.98.11

 Attachments: HBASE-12914-0.98.patch, HBASE-12914-branch-1.patch, 
 HBASE-12914.patch


 There are several features in 0.98 that require enabling HFilev3 support. 
 Some of those features include new extendable components that are marked 
 IA.Public.
 Current practice has been to treat these features as experimental. This has 
 included pushing non-compatible changes to branch-1 as the API got worked out 
 through use in 0.98.
 * Update all of the IA.Public classes involved to make sure they are 
 IS.Unstable in 0.98.
 * Update the ref guide section on upgrading from 0.98 - 1.0 to make folks 
 aware of these changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12959) Compact never end when table's dataBlockEncoding using PREFIX_TREE

2015-02-03 Thread zhangduo (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304717#comment-14304717
 ] 

zhangduo commented on HBASE-12959:
--

[~bdifn] Have you tried 0.98.10RC2? You can download it here.
http://people.apache.org/~apurtell/0.98.10RC2/

HBASE-12817 have fixed a prefix tree decoding issue and will be released with 
0.98.10.

Thanks~

  Compact never end when table's dataBlockEncoding using  PREFIX_TREE
 

 Key: HBASE-12959
 URL: https://issues.apache.org/jira/browse/HBASE-12959
 Project: HBase
  Issue Type: Bug
  Components: hbase
Affects Versions: 0.98.7
 Environment: hbase 0.98.7
 hadoop 2.5.1
Reporter: wuchengzhi
Priority: Critical
 Attachments: PrefixTreeCompact.java, txtfile-part1.txt.gz, 
 txtfile-part2.txt.gz, txtfile-part4.txt.gz, txtfile-part5.txt.gz, 
 txtfile-part6.txt.gz, txtfile-part7.txt.gz


 I upgraded the hbase from 0.96.1.1 to 0.98.7 and hadoop from 2.2.0 to 
 2.5.1,some table encoding using prefix-tree was abnormal for compacting,  the 
 gui shows the table's Compaction status is MAJOR_AND_MINOR(MAJOR) all the 
 time.
 in the regionserver dump , there are some logs as below:
 Tasks:
 ===
 Task: Compacting info in 
 PREFIX_NOT_COMPACT,,1421954285670.41ef60e2c221772626e141d5080296c5.
 Status: RUNNING:Compacting store info
 Running for 1097s  (on the  site running more than 3 days)
 
 Thread 197 (regionserver60020-smallCompactions-1421954341530):
   State: RUNNABLE
   Blocked count: 7
   Waited count: 3
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.followFan(PrefixTreeArrayScanner.java:329)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:149)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.seekForwardToOrAfter(PrefixTreeArraySearcher.java:183)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToOrBeforeUsingPositionAtOrAfter(PrefixTreeSeeker.java:199)
 
 org.apache.hadoop.hbase.codec.prefixtree.PrefixTreeSeeker.seekToKeyInBlock(PrefixTreeSeeker.java:162)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$EncodedScannerV2.loadBlockAndSeekToKey(HFileReaderV2.java:1172)
 
 org.apache.hadoop.hbase.io.hfile.HFileReaderV2$AbstractScannerV2.reseekTo(HFileReaderV2.java:573)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseekAtOrAfter(StoreFileScanner.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(StoreFileScanner.java:173)
 
 org.apache.hadoop.hbase.regionserver.NonLazyKeyValueScanner.doRealSeek(NonLazyKeyValueScanner.java:55)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.generalizedSeek(KeyValueHeap.java:313)
 
 org.apache.hadoop.hbase.regionserver.KeyValueHeap.reseek(KeyValueHeap.java:257)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.reseek(StoreScanner.java:697)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.seekAsDirection(StoreScanner.java:683)
 
 org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:533)
 
 org.apache.hadoop.hbase.regionserver.compactions.Compactor.performCompaction(Compactor.java:222)
 
 org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:77)
 
 org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:110)
 org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1099)
 org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1482)
 Thread 177 (regionserver60020-smallCompactions-1421954314809):
   State: RUNNABLE
   Blocked count: 40
   Waited count: 60
   Stack:
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.column.ColumnReader.populateBuffer(ColumnReader.java:81)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateQualifier(PrefixTreeArrayScanner.java:471)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.populateNonRowFields(PrefixTreeArrayScanner.java:452)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.nextRow(PrefixTreeArrayScanner.java:226)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArrayScanner.advance(PrefixTreeArrayScanner.java:208)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtQualifierTimestamp(PrefixTreeArraySearcher.java:244)
 
 org.apache.hadoop.hbase.codec.prefixtree.decode.PrefixTreeArraySearcher.positionAtOrAfter(PrefixTreeArraySearcher.java:123)

[jira] [Commented] (HBASE-12965) Enhance the delete option to pass Filters

2015-02-03 Thread Anoop Sam John (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304708#comment-14304708
]

Anoop Sam John commented on HBASE-12965:

BulkDeleteEndPoint is added for such use case. Here there is no need to fetch
rows back to client and find out RKs from that and issue deletes again. The EP
runs at server side avoiding too many RPCs and data flow btw server and client.
I agree that it might be bit challenging for users to write code to invoke
this EP. (Any EP). So what we can do, IMO, is to add some thing like a Client
service class which will take the head ache of calling this EP.
Just like we have AggregationEP and AggregationClient.

What do you think?

Enhance the delete option to pass Filters
-

Key: HBASE-12965
URL: https://issues.apache.org/jira/browse/HBASE-12965
Project: HBase
Issue Type: Improvement
Components: API, Deletes, Filters
Affects Versions: 0.98.10
Reporter: IMRANKHAN SHAJAHAN

Scan having the option to pass FIlters and filter the rows based on the
filter.
But for deleting rows, there is no easy way to pass the filters to Delete
Object.
We can do that using below three approach
1) Scan the records and create list of Delete object and do the delete. This
needs iteration in client side.
2) Writing map reduce
3) BulkDeleteEndPoint
If we implement the option of passing filters in Delete Object, then we dont
need to worry about option 2 and 3.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12965) Enhance the delete option to pass Filters

2015-02-03 Thread Nick Dimiduk (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304725#comment-14304725
 ] 

Nick Dimiduk commented on HBASE-12965:
--

Agreed, BulkDelete seems like what you want. 
https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/coprocessor/example/BulkDeleteEndpoint.html

Maybe it's worth promoting this to the Table API? How about Table#delete(Scan) 
instead of a coproc invocation?

 Enhance the delete option to pass Filters
 -

 Key: HBASE-12965
 URL: https://issues.apache.org/jira/browse/HBASE-12965
 Project: HBase
  Issue Type: Improvement
  Components: API, Deletes, Filters
Affects Versions: 0.98.10
Reporter: IMRANKHAN SHAJAHAN

 Scan having the option to pass FIlters and filter the rows based on the 
 filter.
 But for deleting rows, there is no easy way to pass the filters to Delete 
 Object.
 We can do that using below three approach
 1) Scan the records and create list of Delete object and do the delete. This 
 needs iteration in client side.
 2) Writing map reduce
 3) BulkDeleteEndPoint
 If we implement the option of passing filters in Delete Object, then we dont 
 need to worry about option 2 and 3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12960) Cannot run the hbase shell command on Windows

2015-02-03 Thread Lukas Eder (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304738#comment-14304738
 ] 

Lukas Eder commented on HBASE-12960:


I'm sorry I've already deleted HBase as it was the wrong version for me anyway. 
I'll remember to create patches next time.

 Cannot run the hbase shell command on Windows
 ---

 Key: HBASE-12960
 URL: https://issues.apache.org/jira/browse/HBASE-12960
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 0.99.2
 Environment: Windows 8.1
Reporter: Lukas Eder
Priority: Minor

 I've just downloaded and unzipped hbase 0.99.2 and tried to run this command:
 {code}
 C:\hbase-0.99.2\binhbase shell
 Invalid maximum heap size: -Xmx1000m 
 Error: Could not create the Java Virtual Machine.
 Error: A fatal exception has occurred. Program will exit.
 {code}
 The command is documented here:
 http://hbase.apache.org/book.html#_get_started_with_hbase
 The problem is in hbase.cmd on line 296
 {code}
 set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
 {code}
 The quotes should be stripped:
 {code}
 set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12962) TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531


[ 
https://issues.apache.org/jira/browse/HBASE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304760#comment-14304760
 ] 

Hudson commented on HBASE-12962:


SUCCESS: Integrated in HBase-1.0 #707 (See 
[https://builds.apache.org/job/HBase-1.0/707/])
HBASE-12962 - TestHFileBlockIndex.testBlockIndex() commented out during 
(ramkrishna: rev 9539373ca62a12b1d86e641ee8bd00526d30eeae)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java


 TestHFileBlockIndex.testBlockIndex() commented out during HBASE-10531
 -

 Key: HBASE-12962
 URL: https://issues.apache.org/jira/browse/HBASE-12962
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.0.0, 2.0.0, 1.0.1
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 1.0.0, 2.0.0, 1.0.1

 Attachments: HBASE-12962.patch


 Accidentally during HBASE-10531 the test case testBlockIndex() in 
 TestHFileBlockIndex was commented out.  Apologies for that. Not sure how that 
 happened. This patch uncomments the commented out test case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12957) region_mover#isSuccessfulScan may be extremely slow on region with lots of expired data


[ 
https://issues.apache.org/jira/browse/HBASE-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304735#comment-14304735
 ] 

Hudson commented on HBASE-12957:


FAILURE: Integrated in HBase-TRUNK #6085 (See 
[https://builds.apache.org/job/HBase-TRUNK/6085/])
HBASE-12957  Revert accidental checkin of unrelated test (tedyu: rev 
fd0bb89fdf67d996e8cc678d81c6acb799c2cc49)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerHostname.java


 region_mover#isSuccessfulScan may be extremely slow on region with lots of 
 expired data
 ---

 Key: HBASE-12957
 URL: https://issues.apache.org/jira/browse/HBASE-12957
 Project: HBase
  Issue Type: Improvement
  Components: scripts
Reporter: hongyu bi
Assignee: hongyu bi
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-12957-v0.patch


 region_mover will call isSuccessfulScan when region has moved to make sure 
 it's healthy, however , if the moved region has lots of expired data 
 region_mover#isSuccessfulScan will take a long time to finish ,that may even 
 exceed lease timeout.So I made isSuccessfulScan a get-like scan to achieve 
 faster response in that case. 
 workaround:before graceful_stop/rolling_restart ，call major_compact on the 
 table with small TTL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12960) Cannot run the hbase shell command on Windows

2015-02-03 Thread Lukas Eder (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303444#comment-14303444
 ] 

Lukas Eder commented on HBASE-12960:


In fact, line 91 also needs to be adapted:

Wrong:

{code}
set JAVA_OFFHEAP_MAX=
{code}

Correct:

{code}
set JAVA_OFFHEAP_MAX=
{code}

 Cannot run the hbase shell command on Windows
 ---

 Key: HBASE-12960
 URL: https://issues.apache.org/jira/browse/HBASE-12960
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 0.99.2
 Environment: Windows 8.1
Reporter: Lukas Eder
Priority: Minor

 I've just downloaded and unzipped hbase 0.99.2 and tried to run this command:
 {code}
 C:\hbase-0.99.2\binhbase shell
 Invalid maximum heap size: -Xmx1000m 
 Error: Could not create the Java Virtual Machine.
 Error: A fatal exception has occurred. Program will exit.
 {code}
 The command is documented here:
 http://hbase.apache.org/book.html#_get_started_with_hbase
 The problem is in hbase.cmd on line 296
 {code}
 set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
 {code}
 The quotes should be stripped:
 {code}
 set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12108) HBaseConfiguration

2015-02-03 Thread Aniket Bhatnagar (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14303421#comment-14303421
 ] 

Aniket Bhatnagar commented on HBASE-12108:
--

I don't think adding a test case for this is plausible. The test would have to 
construct a class loader containing HBASE jar with it's parent class loader 
having hadoop jars. For constructing classpaths, we would need to pull in jars 
that seems like a bad idea for a test case.

 HBaseConfiguration
 --

 Key: HBASE-12108
 URL: https://issues.apache.org/jira/browse/HBASE-12108
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.6
Reporter: Aniket Bhatnagar
Priority: Minor
  Labels: class_loader, configuration, patch
 Attachments: HBaseConfiguration_HBASE_HBASE-12108.patch


 IN the setup wherein HBase jars are loaded in child classloader whose parent 
 had loaded hadoop-common jar, HBaseConfiguration.create() throws 
 hbase-default.xml file seems to be for and old version of HBase (null)...  
 exception. ClassLoader should be set in Hadoop conf object before calling 
 addHbaseResources method



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-12960) Cannot run the hbase shell command on Windows

2015-02-03 Thread Lukas Eder (JIRA)

Lukas Eder created HBASE-12960:
--

 Summary: Cannot run the hbase shell command on Windows
 Key: HBASE-12960
 URL: https://issues.apache.org/jira/browse/HBASE-12960
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 0.99.2
 Environment: Windows 8.1
Reporter: Lukas Eder
Priority: Minor


I've just downloaded and unzipped hbase 0.99.2 and tried to run this command:

{code}
C:\hbase-0.99.2\binhbase shell
Invalid maximum heap size: -Xmx1000m 
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
{code}

The command is documented here:
http://hbase.apache.org/book.html#_get_started_with_hbase

The problem is in hbase.cmd on line 296

{code}
set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
{code}

The quotes should be stripped:

{code}
set HEAP_SETTINGS=%JAVA_HEAP_MAX% %JAVA_OFFHEAP_MAX%
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-8329) Limit compaction speed

2015-02-03 Thread zhangduo (JIRA)


 [ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhangduo updated HBASE-8329:

Attachment: HBASE-8329-0.98.patch

Patch for 0.98.

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-0.98.patch, HBASE-8329-10.patch, 
 HBASE-8329-11.patch, HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, 
 HBASE-8329-3-trunk.patch, HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, 
 HBASE-8329-6-trunk.patch, HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, 
 HBASE-8329-9-trunk.patch, HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, 
 HBASE-8329_13.patch, HBASE-8329_14.patch, HBASE-8329_15.patch, 
 HBASE-8329_16.patch, HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-8329) Limit compaction speed

2015-02-03 Thread zhangduo (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302918#comment-14302918
 ] 

zhangduo commented on HBASE-8329:
-

[~apurtell] Just post it here or open a backport issue?
The issue is resolved and the discussion here is too long I think.

 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-10.patch, HBASE-8329-11.patch, 
 HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, HBASE-8329-3-trunk.patch, 
 HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, HBASE-8329-6-trunk.patch, 
 HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, HBASE-8329-9-trunk.patch, 
 HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, HBASE-8329_13.patch, 
 HBASE-8329_14.patch, HBASE-8329_15.patch, HBASE-8329_16.patch, 
 HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-12954) Ability impaired using HBase on multihomed hosts

2015-02-03 Thread Andrew Purtell (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302936#comment-14302936
]

Andrew Purtell commented on HBASE-12954:

I see your concerns about the mapping file notion, because it is a separate
file from HBase-site and therefore another opportunity to introduce
configuration error. It also doesn't seem to hit the mark for you. We don't
need to consider it further.

If we do introduce an option for assigning regionservers a canonical name in
their site file and having them send it off to the master with a forcing flag
or similar, then I think we would need to ensure it is not default behavior and
document it as wizard level configuration not recommended normally.

Ability impaired using HBase on multihomed hosts

Key: HBASE-12954
URL: https://issues.apache.org/jira/browse/HBASE-12954
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.4
Reporter: Clay B.
Assignee: Ted Yu
Priority: Minor
Attachments: 12954-v1.txt, Hadoop Three Interfaces.png

For HBase clusters running on unusual networks (such as NAT'd cloud
environments or physical machines with multiple IP's per network interface)
it would be ideal to have a way to both specify:
# which IP interface to which HBase master or region-server will bind
# what hostname HBase will advertise in Zookeeper both for a master or
region-server process
While efforts such as HBASE-8640 go a long way to normalize these two sources
of information, it is not possible in the current design of the properties
available to an administrator for these to be unambiguously specified.
One has been able to request {{hbase.master.ipc.address}} or
{{hbase.regionserver.ipc.address}} but one can not specify the desired HBase
{{hbase.master.hostname}}. (It was removed in HBASE-1357, further I am
unaware of a region-server equivalent.)
I use a configuration management system to generate all of my configuration
files on a per-machine basis. As such, an option to generate a file
specifying exactly which hostname to use would be helpful.
Today, specifying the bind address for HBase works and one can use an
HBase-only DNS for faking what to put in Zookeeper but this is far from
ideal. Network interfaces have no intrinsic IP address, nor hostname.
Specifing a DNS server is awkward as the DNS server may differ from the
system's resolver and is a single IP address. Similarly, on hosts which use a
transient VIP (e.g. through keepalived) for other services, it means there's
a seemingly non-deterministic hostname choice made by HBase depending on the
state of the VIP at daemon start-up time.
I will attach two networking examples I use which become very difficult to
manage under the current properties.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-10942) support parallel request cancellation for multi-get


[ 
https://issues.apache.org/jira/browse/HBASE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302940#comment-14302940
 ] 

Hudson commented on HBASE-10942:


FAILURE: Integrated in HBase-TRUNK #6080 (See 
[https://builds.apache.org/job/HBase-TRUNK/6080/])
HBASE-10942. support parallel request cancellation for multi-get (Nicolas 
Liochon  Devaraj Das) (ddas: rev cf5ad96fcc2ac02889e8a96a5d99cac071e1f25c)
* 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiServerCallable.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/AsyncRpcChannel.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestReplicasClient.java


 support parallel request cancellation for multi-get
 ---

 Key: HBASE-10942
 URL: https://issues.apache.org/jira/browse/HBASE-10942
 Project: HBase
  Issue Type: Sub-task
Reporter: Sergey Shelukhin
Assignee: Devaraj Das
 Fix For: 1.1.0

 Attachments: 10942-1.1.txt, 10942-branch-1.txt, 10942-for-98.zip, 
 10942.patch, HBASE-10942.01.patch, HBASE-10942.02.patch, HBASE-10942.patch






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-8329) Limit compaction speed


[ 
https://issues.apache.org/jira/browse/HBASE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302939#comment-14302939
 ] 

Hudson commented on HBASE-8329:
---

FAILURE: Integrated in HBase-TRUNK #6080 (See 
[https://builds.apache.org/job/HBase-TRUNK/6080/])
HBASE-8329 Limit compaction speed (stack: rev 
eb351b9ff8276228e725bcf58675ab75b640fbbf)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/MockRegionServerServices.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionContext.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStripeCompactor.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverScannerOpenHook.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestStripeCompactionPolicy.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionThroughputController.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StripeStoreFileManager.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultStoreEngine.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplitThread.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompaction.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStripeStoreEngine.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/StripeCompactor.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestCompactionWithThroughputController.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/PressureAwareCompactionThroughputController.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactionTool.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StripeStoreEngine.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestHCM.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultStoreFileManager.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStore.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionThroughputControllerFactory.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/DefaultCompactor.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/NoLimitCompactionThroughputController.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileManager.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/StripeCompactionPolicy.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/TestIOFencing.java


 Limit compaction speed
 --

 Key: HBASE-8329
 URL: https://issues.apache.org/jira/browse/HBASE-8329
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Reporter: binlijin
Assignee: zhangduo
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-8329-0.98.patch, HBASE-8329-10.patch, 
 HBASE-8329-11.patch, HBASE-8329-12.patch, HBASE-8329-2-trunk.patch, 
 HBASE-8329-3-trunk.patch, HBASE-8329-4-trunk.patch, HBASE-8329-5-trunk.patch, 
 HBASE-8329-6-trunk.patch, HBASE-8329-7-trunk.patch, HBASE-8329-8-trunk.patch, 
 HBASE-8329-9-trunk.patch, HBASE-8329-branch-1.patch, HBASE-8329-trunk.patch, 
 HBASE-8329_13.patch, HBASE-8329_14.patch, HBASE-8329_15.patch, 
 HBASE-8329_16.patch, HBASE-8329_17.patch


 There is no speed or resource limit for compaction，I think we should add this 
 feature especially when request burst.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-10942) support parallel request cancellation for multi-get