[jira] [Updated] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya Kishore updated HBASE-7095: -- Attachment: HBASE-7095_trunk.patch > Can not set 'lenAsVal' for KeyOnlyFilter from shell > --- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
Aditya Kishore created HBASE-7095: - Summary: Can not set 'lenAsVal' for KeyOnlyFilter from shell Key: HBASE-7095 URL: https://issues.apache.org/jira/browse/HBASE-7095 Project: HBase Issue Type: Bug Components: Filters Affects Versions: 0.96.0 Reporter: Aditya Kishore Priority: Minor Attachments: HBASE-7095_trunk.patch Current implementation of createFilterFromArguments() in KeyOnlyFilter rejects the Boolean argument, effectively preventing from specifying this option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aditya Kishore updated HBASE-7095: -- Assignee: Aditya Kishore > Can not set 'lenAsVal' for KeyOnlyFilter from shell > --- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[
https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aditya Kishore updated HBASE-7095:
--
Fix Version/s: 0.96.0
Status: Patch Available (was: Open)
Submitting patch for trunk. Now the option can be specified from shell using
the filter language.
{code}
scan 't1', {FILTER => "KeyOnlyFilter(true)"}
{code}
> Can not set 'lenAsVal' for KeyOnlyFilter from shell
> ---
>
> Key: HBASE-7095
> URL: https://issues.apache.org/jira/browse/HBASE-7095
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Labels: shell
> Fix For: 0.96.0
>
> Attachments: HBASE-7095_trunk.patch
>
>
> Current implementation of createFilterFromArguments() in KeyOnlyFilter
> rejects the Boolean argument, effectively preventing from specifying this
> option from HBase shell.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7096) CustomHBaseFilter is missing in the REST interface
Alexander Alten-Lorenz created HBASE-7096:
-
Summary: CustomHBaseFilter is missing in the REST interface
Key: HBASE-7096
URL: https://issues.apache.org/jira/browse/HBASE-7096
Project: HBase
Issue Type: Bug
Components: REST
Affects Versions: 0.94.2
Reporter: Alexander Alten-Lorenz
src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
static enum FilterType {
ColumnCountGetFilter,
ColumnPaginationFilter,
ColumnPrefixFilter,
ColumnRangeFilter,
DependentColumnFilter,
FamilyFilter,
FilterList,
FirstKeyOnlyFilter,
InclusiveStopFilter,
KeyOnlyFilter,
MultipleColumnPrefixFilter,
PageFilter,
PrefixFilter,
QualifierFilter,
RandomRowFilter,
RowFilter,
SingleColumnValueExcludeFilter,
SingleColumnValueFilter,
SkipFilter,
TimestampsFilter,
ValueFilter,
WhileMatchFilter
}
CustomHBaseFilter is missing in the REST interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7096) CustomHBaseFilter is missing in the REST interface
[
https://issues.apache.org/jira/browse/HBASE-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Alten-Lorenz updated HBASE-7096:
--
Description:
{code}
src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
static enum FilterType {
ColumnCountGetFilter,
ColumnPaginationFilter,
ColumnPrefixFilter,
ColumnRangeFilter,
DependentColumnFilter,
FamilyFilter,
FilterList,
FirstKeyOnlyFilter,
InclusiveStopFilter,
KeyOnlyFilter,
MultipleColumnPrefixFilter,
PageFilter,
PrefixFilter,
QualifierFilter,
RandomRowFilter,
RowFilter,
SingleColumnValueExcludeFilter,
SingleColumnValueFilter,
SkipFilter,
TimestampsFilter,
ValueFilter,
WhileMatchFilter
}
{code}
CustomHBaseFilter is missing in the REST interface.
was:
src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
static enum FilterType {
ColumnCountGetFilter,
ColumnPaginationFilter,
ColumnPrefixFilter,
ColumnRangeFilter,
DependentColumnFilter,
FamilyFilter,
FilterList,
FirstKeyOnlyFilter,
InclusiveStopFilter,
KeyOnlyFilter,
MultipleColumnPrefixFilter,
PageFilter,
PrefixFilter,
QualifierFilter,
RandomRowFilter,
RowFilter,
SingleColumnValueExcludeFilter,
SingleColumnValueFilter,
SkipFilter,
TimestampsFilter,
ValueFilter,
WhileMatchFilter
}
CustomHBaseFilter is missing in the REST interface.
> CustomHBaseFilter is missing in the REST interface
> --
>
> Key: HBASE-7096
> URL: https://issues.apache.org/jira/browse/HBASE-7096
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 0.94.2
>Reporter: Alexander Alten-Lorenz
>
> {code}
> src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
> static enum FilterType {
> ColumnCountGetFilter,
> ColumnPaginationFilter,
> ColumnPrefixFilter,
> ColumnRangeFilter,
> DependentColumnFilter,
> FamilyFilter,
> FilterList,
> FirstKeyOnlyFilter,
> InclusiveStopFilter,
> KeyOnlyFilter,
> MultipleColumnPrefixFilter,
> PageFilter,
> PrefixFilter,
> QualifierFilter,
> RandomRowFilter,
> RowFilter,
> SingleColumnValueExcludeFilter,
> SingleColumnValueFilter,
> SkipFilter,
> TimestampsFilter,
> ValueFilter,
> WhileMatchFilter
>}
> {code}
> CustomHBaseFilter is missing in the REST interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7096) Support customer filters in REST API
[
https://issues.apache.org/jira/browse/HBASE-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Alten-Lorenz updated HBASE-7096:
--
Summary: Support customer filters in REST API (was: CustomHBaseFilter is
missing in the REST interface)
> Support customer filters in REST API
>
>
> Key: HBASE-7096
> URL: https://issues.apache.org/jira/browse/HBASE-7096
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 0.94.2
>Reporter: Alexander Alten-Lorenz
>
> {code}
> src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
> static enum FilterType {
> ColumnCountGetFilter,
> ColumnPaginationFilter,
> ColumnPrefixFilter,
> ColumnRangeFilter,
> DependentColumnFilter,
> FamilyFilter,
> FilterList,
> FirstKeyOnlyFilter,
> InclusiveStopFilter,
> KeyOnlyFilter,
> MultipleColumnPrefixFilter,
> PageFilter,
> PrefixFilter,
> QualifierFilter,
> RandomRowFilter,
> RowFilter,
> SingleColumnValueExcludeFilter,
> SingleColumnValueFilter,
> SkipFilter,
> TimestampsFilter,
> ValueFilter,
> WhileMatchFilter
>}
> {code}
> CustomHBaseFilter is missing in the REST interface.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7096) Support customer filters in REST API
[
https://issues.apache.org/jira/browse/HBASE-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Alten-Lorenz updated HBASE-7096:
--
Description:
{code}
src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
static enum FilterType {
ColumnCountGetFilter,
ColumnPaginationFilter,
ColumnPrefixFilter,
ColumnRangeFilter,
DependentColumnFilter,
FamilyFilter,
FilterList,
FirstKeyOnlyFilter,
InclusiveStopFilter,
KeyOnlyFilter,
MultipleColumnPrefixFilter,
PageFilter,
PrefixFilter,
QualifierFilter,
RandomRowFilter,
RowFilter,
SingleColumnValueExcludeFilter,
SingleColumnValueFilter,
SkipFilter,
TimestampsFilter,
ValueFilter,
WhileMatchFilter
}
{code}
The REST API should support customer filters like the HBase API.
was:
{code}
src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
static enum FilterType {
ColumnCountGetFilter,
ColumnPaginationFilter,
ColumnPrefixFilter,
ColumnRangeFilter,
DependentColumnFilter,
FamilyFilter,
FilterList,
FirstKeyOnlyFilter,
InclusiveStopFilter,
KeyOnlyFilter,
MultipleColumnPrefixFilter,
PageFilter,
PrefixFilter,
QualifierFilter,
RandomRowFilter,
RowFilter,
SingleColumnValueExcludeFilter,
SingleColumnValueFilter,
SkipFilter,
TimestampsFilter,
ValueFilter,
WhileMatchFilter
}
{code}
CustomHBaseFilter is missing in the REST interface.
> Support customer filters in REST API
>
>
> Key: HBASE-7096
> URL: https://issues.apache.org/jira/browse/HBASE-7096
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 0.94.2
>Reporter: Alexander Alten-Lorenz
>
> {code}
> src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
> static enum FilterType {
> ColumnCountGetFilter,
> ColumnPaginationFilter,
> ColumnPrefixFilter,
> ColumnRangeFilter,
> DependentColumnFilter,
> FamilyFilter,
> FilterList,
> FirstKeyOnlyFilter,
> InclusiveStopFilter,
> KeyOnlyFilter,
> MultipleColumnPrefixFilter,
> PageFilter,
> PrefixFilter,
> QualifierFilter,
> RandomRowFilter,
> RowFilter,
> SingleColumnValueExcludeFilter,
> SingleColumnValueFilter,
> SkipFilter,
> TimestampsFilter,
> ValueFilter,
> WhileMatchFilter
>}
> {code}
> The REST API should support customer filters like the HBase API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490198#comment-13490198 ] Ted Yu commented on HBASE-7095: --- Patch looks good. Looks like Hadoop QA hasn't run test suite due to Jenkins issue. > Can not set 'lenAsVal' for KeyOnlyFilter from shell > --- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7092) RegionServer OOM with jdk 1.7 related to ConcurrentHashMap class loader
[ https://issues.apache.org/jira/browse/HBASE-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490202#comment-13490202 ] Jimmy Xiang commented on HBASE-7092: I do have a heap dump which is more than 4GB. I am using 1.7_9. I will try 1.6 and see if I get the same issue so that I can find out it is really a jdk issue or a new code issue. > RegionServer OOM with jdk 1.7 related to ConcurrentHashMap class loader > --- > > Key: HBASE-7092 > URL: https://issues.apache.org/jira/browse/HBASE-7092 > Project: HBase > Issue Type: Sub-task >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.96.0 > > > One instance of "java.util.concurrent.ConcurrentHashMap" loaded by " class loader>" occupies 3,972,154,848 (92.88%) bytes. The instance is > referenced by org.apache.hadoop.hbase.regionserver.HRegionServer @ > 0x7038d3798 , loaded by "sun.misc.Launcher$AppClassLoader @ 0x703994668". The > memory is accumulated in one instance of > "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded by " loader>". > Keywords > sun.misc.Launcher$AppClassLoader @ 0x703994668 > java.util.concurrent.ConcurrentHashMap > java.util.concurrent.ConcurrentHashMap$Segment[] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6331) Problem with HBCK mergeOverlaps
[
https://issues.apache.org/jira/browse/HBASE-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490204#comment-13490204
]
Jimmy Xiang commented on HBASE-6331:
Should we close this now? We can re-open it or create a new one once it can be
reproduced.
> Problem with HBCK mergeOverlaps
> ---
>
> Key: HBASE-6331
> URL: https://issues.apache.org/jira/browse/HBASE-6331
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 0.96.0
>
> Attachments: HBASE-6331_94.patch, HBASE-6331_Trunk.patch
>
>
> In HDFSIntegrityFixer#mergeOverlaps(), there is a logic to create the final
> range of the region after the overlap.
> I can see one issue with this code
> {code}
> if (RegionSplitCalculator.BYTES_COMPARATOR
> .compare(hi.getEndKey(), range.getSecond()) > 0) {
> range.setSecond(hi.getEndKey());
> }
> {code}
> Here suppose the regions include the end region for which the endKey will be
> empty, we need to get finally the range with endkey as empty byte[]
> But as per the above logic it will see that any other key greater than the
> empty byte[] and will set it.
> Finally the new region created will not get endkey as empty byte[]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-2645) HLog writer can do 1-2 sync operations after lease has been recovered for split process.
[ https://issues.apache.org/jira/browse/HBASE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490226#comment-13490226 ] Hudson commented on HBASE-2645: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-2645 HLog writer can do 1-2 sync operations after lease has been recovered for split process; REVERT -- TEST FAILS (Revision 1404875) Result = FAILURE stack : Files : * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java > HLog writer can do 1-2 sync operations after lease has been recovered for > split process. > > > Key: HBASE-2645 > URL: https://issues.apache.org/jira/browse/HBASE-2645 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.90.4 >Reporter: Cosmin Lehene >Assignee: Todd Lipcon >Priority: Blocker > Fix For: 0.96.0 > > Attachments: 2645.txt, 2645v2.txt, 2645v3.txt, > org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit-output.txt > > > TestHLogSplit.testLogCannotBeWrittenOnceParsed is failing. > This test starts a thread that writes one edit to the log, syncs and counts. > During this, a HLog.splitLog operation is started. splitLog recovers the log > lease before reading the log, so that the original regionserver could not > wake up and write after the split process started. > The test compares the number of edits reported by the split process and by > the writer thread. Writer thread (called zombie in the test) should report <= > than the splitLog (sync() might raise after the last edit gets written and > the edit won't get counted by zombie thread). However it appears that the > zombie counts 1-2 more edits. So it looks like it can sync without a lease. > This might be a hdfs-0.20 related issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7070) Scanner may retry forever after HBASE-5974
[ https://issues.apache.org/jira/browse/HBASE-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490227#comment-13490227 ] Hudson commented on HBASE-7070: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-7070 Scanner may retry forever after HBASE-5974 (Revision 1405107) Result = FAILURE stack : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientScannerRPCTimeout.java > Scanner may retry forever after HBASE-5974 > --- > > Key: HBASE-7070 > URL: https://issues.apache.org/jira/browse/HBASE-7070 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.96.0 >Reporter: chunhui shen >Assignee: chunhui shen > Fix For: 0.96.0 > > Attachments: HBASE-7070.patch, HBASE-7070v2.patch, > HBASE-7070v3.patch, HBASE-7070v4.patch, HBASE-7070v5.patch, HBASE-7070v6.patch > > > After the patch of HBASE-5974 > Suppose The process is as the following: > 1.A next request is very large, so first time it is failed because of timeout > 2.The second time it is failed again because of > CallSequenceOutOfOrderException > 3.We will retry this next request again after reset scanner, so it is also > very large and failed again because of timeout > 4.CallSequenceOutOfOrderException again > 5.Repeated the above forever... > See the comment in HBASE-5974 for more > https://issues.apache.org/jira/browse/HBASE-5974?focusedCommentId=13486658&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13486658 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6389) Modify the conditions to ensure that Master waits for sufficient number of Region Servers before starting region assignments
[
https://issues.apache.org/jira/browse/HBASE-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490228#comment-13490228
]
Hudson commented on HBASE-6389:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/])
HBASE-6389 Modify the conditions to ensure that Master waits for sufficient
number of Region Servers before starting region assignments (Revision 1405111)
Result = FAILURE
stack :
Files :
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/TestZooKeeper.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMasterNoCluster.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRSKilledWhenMasterInitializing.java
> Modify the conditions to ensure that Master waits for sufficient number of
> Region Servers before starting region assignments
>
>
> Key: HBASE-6389
> URL: https://issues.apache.org/jira/browse/HBASE-6389
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Critical
> Fix For: 0.94.3, 0.96.0
>
> Attachments: HBASE-6389_0.94.patch, HBASE-6389_trunk.patch,
> HBASE-6389_trunk.patch, HBASE-6389_trunk.patch, HBASE-6389_trunk_v2.patch,
> HBASE-6389_trunk_v2.patch, org.apache.hadoop.hbase.TestZooKeeper-output.txt,
> testReplication.jstack
>
>
> Continuing from HBASE-6375.
> It seems I was mistaken in my assumption that changing the value of
> "hbase.master.wait.on.regionservers.mintostart" to a sufficient number (from
> default of 1) can help prevent assignment of all regions to one (or a small
> number of) region server(s).
> While this was the case in 0.90.x and 0.92.x, the behavior has changed in
> 0.94.0 onwards to address HBASE-4993.
> From 0.94.0 onwards, Master will proceed immediately after the timeout has
> lapsed, even if "hbase.master.wait.on.regionservers.mintostart" has not
> reached.
> Reading the current conditions of waitForRegionServers() clarifies it
> {code:title=ServerManager.java (trunk rev:1360470)}
>
> 581 /**
> 582 * Wait for the region servers to report in.
> 583 * We will wait until one of this condition is met:
> 584 * - the master is stopped
> 585 * - the 'hbase.master.wait.on.regionservers.timeout' is reached
> 586 * - the 'hbase.master.wait.on.regionservers.maxtostart' number of
> 587 *region servers is reached
> 588 * - the 'hbase.master.wait.on.regionservers.mintostart' is reached
> AND
> 589 * there have been no new region server in for
> 590 * 'hbase.master.wait.on.regionservers.interval' time
> 591 *
> 592 * @throws InterruptedException
> 593 */
> 594 public void waitForRegionServers(MonitoredTask status)
> 595 throws InterruptedException {
>
>
> 612 while (
> 613 !this.master.isStopped() &&
> 614 slept < timeout &&
> 615 count < maxToStart &&
> 616 (lastCountChange+interval > now || count < minToStart)
> 617 ){
>
> {code}
> So with the current conditions, the wait will end as soon as timeout is
> reached even lesser number of RS have checked-in with the Master and the
> master will proceed with the region assignment among these RSes alone.
> As mentioned in
> -[HBASE-4993|https://issues.apache.org/jira/browse/HBASE-4993?focusedCommentId=13237196#comment-13237196]-,
> and I concur, this could have disastrous effect in large cluster especially
> now that MSLAB is turned on.
> To enforce the required quorum as specified by
> "hbase.master.wait.on.regionservers.mintostart" irrespective of timeout,
> these conditions need to be modified as following
> {code:title=ServerManager.java}
> ..
> /**
>* Wait for the region servers to report in.
>* We will wait until one of this condition is met:
>* - the master is stopped
>* - the 'hbase.master.wait.on.regionservers.maxtostart' number of
>*region servers is reached
>* - the 'hbase.master.wait.on.regionservers.mintostart' is reached AND
>* there have been no new region server in for
>* 'hbase.master.wait.on.regionservers.interval' time AND
>* the 'hbase.master.wait.on.regionservers.timeout' is reached
>*
>* @throws Inter
[jira] [Commented] (HBASE-5974) Scanner retry behavior with RPC timeout on next() seems incorrect
[ https://issues.apache.org/jira/browse/HBASE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490229#comment-13490229 ] Hudson commented on HBASE-5974: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-7070 Scanner may retry forever after HBASE-5974 (Revision 1405107) Result = FAILURE stack : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/ClientScanner.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientScannerRPCTimeout.java > Scanner retry behavior with RPC timeout on next() seems incorrect > - > > Key: HBASE-5974 > URL: https://issues.apache.org/jira/browse/HBASE-5974 > Project: HBase > Issue Type: Bug > Components: Client, regionserver >Affects Versions: 0.90.7, 0.92.1, 0.94.0, 0.96.0 >Reporter: Todd Lipcon >Assignee: Anoop Sam John >Priority: Critical > Fix For: 0.96.0 > > Attachments: 5974_94-V4.patch, 5974_trunk.patch, 5974_trunk-V2.patch, > 5974_trunk-V3.patch, HBASE-5974_0.94.patch, HBASE-5974_94-V2.patch, > HBASE-5974_94-V3.patch > > > I'm seeing the following behavior: > - set RPC timeout to a short value > - call next() for some batch of rows, big enough so the client times out > before the result is returned > - the HConnectionManager stuff will retry the next() call to the same server. > At this point, one of two things can happen: 1) the previous next() call will > still be processing, in which case you get a LeaseException, because it was > removed from the map during the processing, or 2) the next() call will > succeed but skip the prior batch of rows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7083) SSH#fixupDaughter should force re-assign missing daughter
[ https://issues.apache.org/jira/browse/HBASE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490231#comment-13490231 ] Hudson commented on HBASE-7083: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-7083 SSH#fixupDaughter should force re-assign missing daughter (Revision 1404867) Result = FAILURE jxiang : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java > SSH#fixupDaughter should force re-assign missing daughter > - > > Key: HBASE-7083 > URL: https://issues.apache.org/jira/browse/HBASE-7083 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Minor > Fix For: 0.96.0 > > Attachments: trunk-7083.patch, trunk-7083.patch > > > In looking into flaky test > TestSplitTransactionOnCluster#testShutdownSimpleFixup, I found out that a > missing daughter is not assigned by SSH properly. It could be open on the > dead server. We need to force re-assign it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7063) Package name for compression should not contain hfile
[ https://issues.apache.org/jira/browse/HBASE-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490232#comment-13490232 ] Hudson commented on HBASE-7063: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-7063 Package name for compression should not contain hfile (Revision 1405130) Result = FAILURE enis : Files : * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/Compression.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/compress/ReusableStreamGzipCodec.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/DataBlockEncoder.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/HFileBlockDecodingContext.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/HFileBlockEncodingContext.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/hfile/ReusableStreamGzipCodec.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/UnmodifyableHColumnDescriptor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/encoding/EncodedDataBlock.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/encoding/HFileBlockDefaultDecodingContext.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/encoding/HFileBlockDefaultEncodingContext.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileReader.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileWriter.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/FixedFileTrailer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileDataBlockEncoder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileDataBlockEncoderImpl.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV1.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV2.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/NoOpDataBlockEncoder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HFileOutputFormat.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Compactor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/thrift/ThriftUtilities.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/CompressionTest.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/HFilePerformanceEvaluation.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/TestHColumnDescriptor.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/encoding/TestDataBlockEncoders.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/encoding/TestEncodedSeekers.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/encoding/TestLoadAndSwitchEncodeOnDisk.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestCacheOnWrite.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestChecksum.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestForceCacheImportantBlocks.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFile.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlock.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockCompatibility.java *
[jira] [Commented] (HBASE-7087) Add to NOTICE.txt a note on jamon being MPL
[ https://issues.apache.org/jira/browse/HBASE-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490233#comment-13490233 ] Hudson commented on HBASE-7087: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/]) HBASE-7087 Add to NOTICE.txt a note on jamon being MPL (Revision 1405073) Result = FAILURE stack : Files : * /hbase/trunk/NOTICE.txt > Add to NOTICE.txt a note on jamon being MPL > --- > > Key: HBASE-7087 > URL: https://issues.apache.org/jira/browse/HBASE-7087 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack > Fix For: 0.94.3, 0.96.0 > > Attachments: 7087.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7086) Enhance ResourceChecker to log stack trace for potentially hanging threads
[
https://issues.apache.org/jira/browse/HBASE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490230#comment-13490230
]
Hudson commented on HBASE-7086:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #248 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/248/])
HBASE-7086 Enhance ResourceChecker to log stack trace for potentially
hanging threads (Revision 1405443)
Result = FAILURE
tedyu :
Files :
*
/hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/ResourceChecker.java
*
/hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/ResourceCheckerJUnitListener.java
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/ServerResourceCheckerJUnitListener.java
> Enhance ResourceChecker to log stack trace for potentially hanging threads
> --
>
> Key: HBASE-7086
> URL: https://issues.apache.org/jira/browse/HBASE-7086
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7086.94, 7086-94.addendum, 7086-trunk.txt,
> 7086-trunk-v2.txt, 7086-trunk-v3.txt, testHFileCleaner.out
>
>
> Currently ResourceChecker logs a line similar to the following if it detects
> potential thread leak:
> {code}
> 2012-11-02 10:18:59,299 INFO [main] hbase.ResourceChecker(157): after
> master.cleaner.TestHFileCleaner#testTTLCleaner: 44 threads (was 43), 145 file
> descriptors (was 145). 0 connections, -thread leak?-
> {code}
> We should enhance the log to include stack trace of the potentially hanging
> thread(s)
> This work was motivated when I investigated test failure in HBASE-6796
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6832) [WINDOWS] Tests should use explicit timestamp for Puts, and not rely on implicit RS timing
[
https://issues.apache.org/jira/browse/HBASE-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490236#comment-13490236
]
Ted Yu commented on HBASE-6832:
---
For patch v4:
{code}
+ * @param initalAmount the inital value to start with
{code}
Typo: initalAmount -> initialAmount
For TestKeepDeletes:
{code}
+EnvironmentEdgeManagerTestHelper.injectEdge(new
IncrementingEnvironmentEdge(3000));
{code}
How was the value of 3000 chosen ?
> [WINDOWS] Tests should use explicit timestamp for Puts, and not rely on
> implicit RS timing
>
>
> Key: HBASE-6832
> URL: https://issues.apache.org/jira/browse/HBASE-6832
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.3, 0.96.0
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Labels: windows
> Attachments: hbase-6832_v1-0.94.patch, hbase-6832_v1-trunk.patch,
> hbase-6832_v4-0.94.patch, hbase-6832_v4-trunk.patch
>
>
> TestRegionObserverBypass.testMulti() fails with
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionObserverBypass.checkRowAndDelete(TestRegionObserverBypass.java:173)
> at
> org.apache.hadoop.hbase.coprocessor.TestRegionObserverBypass.testMulti(TestRegionObserverBypass.java:166)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490292#comment-13490292 ] stack commented on HBASE-7095: -- +1 on patch > Can not set 'lenAsVal' for KeyOnlyFilter from shell > --- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7089) Allow filter to be specified for Get from HBase shell
[
https://issues.apache.org/jira/browse/HBASE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-7089:
-
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Committed to trunk. Thanks for the patch Aditya.
> Allow filter to be specified for Get from HBase shell
> -
>
> Key: HBASE-7089
> URL: https://issues.apache.org/jira/browse/HBASE-7089
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7089_trunk.patch, HBASE-7089_trunk_v2.patch,
> HBASE-7089_trunk_v3.patch, HBASE-7089_trunk_v4.patch
>
>
> Unlike scan, get in HBase shell does not accept FILTER as an argument.
> {noformat}
> hbase(main):001:0> get 'table', 'row3', {FILTER => "ValueFilter (=,
> 'binary:valueX')"}
> COLUMN CELL
> ERROR: Failed parse of {"FILTER"=>"ValueFilter (=, 'binary:valueX')"}, Hash
> Here is some help for this command:
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6628) Add HBASE-6059 to 0.94 branch
[ https://issues.apache.org/jira/browse/HBASE-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490294#comment-13490294 ] stack commented on HBASE-6628: -- Thanks for moving it Lars. Will do it one day. > Add HBASE-6059 to 0.94 branch > - > > Key: HBASE-6628 > URL: https://issues.apache.org/jira/browse/HBASE-6628 > Project: HBase > Issue Type: Task >Reporter: stack > Fix For: 0.94.4 > > > Look at adding HBASE-6059 to 0.94. Its in trunk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Can not set 'lenAsVal' for KeyOnlyFilter from shell
[
https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490311#comment-13490311
]
Hadoop QA commented on HBASE-7095:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12552007/HBASE-7095_trunk.patch
against trunk revision .
{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 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
85 warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 4 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/3223//console
This message is automatically generated.
> Can not set 'lenAsVal' for KeyOnlyFilter from shell
> ---
>
> Key: HBASE-7095
> URL: https://issues.apache.org/jira/browse/HBASE-7095
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Labels: shell
> Fix For: 0.96.0
>
> Attachments: HBASE-7095_trunk.patch
>
>
> Current implementation of createFilterFromArguments() in KeyOnlyFilter
> rejects the Boolean argument, effectively preventing from specifying this
> option from HBase shell.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-7095: -- Summary: Cannot set 'lenAsVal' for KeyOnlyFilter from shell (was: Can not set 'lenAsVal' for KeyOnlyFilter from shell) > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-7095: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490319#comment-13490319 ] Ted Yu commented on HBASE-7095: --- Integrated to trunk. Thanks for the patch, Aditya. Thanks for the review, Stack. > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7096) Support customer filters in REST API
[
https://issues.apache.org/jira/browse/HBASE-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490325#comment-13490325
]
Andrew Purtell commented on HBASE-7096:
---
So you are thinking that REST could somehow figure out and transmit a JSON
representation of the "customer" filter by reflection, or similar? How do you
envision this working? Do you have a patch?
> Support customer filters in REST API
>
>
> Key: HBASE-7096
> URL: https://issues.apache.org/jira/browse/HBASE-7096
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 0.94.2
>Reporter: Alexander Alten-Lorenz
>
> {code}
> src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
> static enum FilterType {
> ColumnCountGetFilter,
> ColumnPaginationFilter,
> ColumnPrefixFilter,
> ColumnRangeFilter,
> DependentColumnFilter,
> FamilyFilter,
> FilterList,
> FirstKeyOnlyFilter,
> InclusiveStopFilter,
> KeyOnlyFilter,
> MultipleColumnPrefixFilter,
> PageFilter,
> PrefixFilter,
> QualifierFilter,
> RandomRowFilter,
> RowFilter,
> SingleColumnValueExcludeFilter,
> SingleColumnValueFilter,
> SkipFilter,
> TimestampsFilter,
> ValueFilter,
> WhileMatchFilter
>}
> {code}
> The REST API should support customer filters like the HBase API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7096) Support customer filters in REST API
[
https://issues.apache.org/jira/browse/HBASE-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-7096:
--
Priority: Minor (was: Major)
> Support customer filters in REST API
>
>
> Key: HBASE-7096
> URL: https://issues.apache.org/jira/browse/HBASE-7096
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 0.94.2
>Reporter: Alexander Alten-Lorenz
>Priority: Minor
>
> {code}
> src/main/java/org/apache/hadoop/hbase/rest/model/ScannerModel.java:
> static enum FilterType {
> ColumnCountGetFilter,
> ColumnPaginationFilter,
> ColumnPrefixFilter,
> ColumnRangeFilter,
> DependentColumnFilter,
> FamilyFilter,
> FilterList,
> FirstKeyOnlyFilter,
> InclusiveStopFilter,
> KeyOnlyFilter,
> MultipleColumnPrefixFilter,
> PageFilter,
> PrefixFilter,
> QualifierFilter,
> RandomRowFilter,
> RowFilter,
> SingleColumnValueExcludeFilter,
> SingleColumnValueFilter,
> SkipFilter,
> TimestampsFilter,
> ValueFilter,
> WhileMatchFilter
>}
> {code}
> The REST API should support customer filters like the HBase API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6356) printStackTrace in FSUtils
[
https://issues.apache.org/jira/browse/HBASE-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490330#comment-13490330
]
Gustavo Anatoly commented on HBASE-6356:
Hi, nkeywal.
I read about your comment and I make a simple update like this:
{noformat}
public boolean accept(Path p) {
boolean isValid = false;
try {
if (HConstants.HBASE_NON_USER_TABLE_DIRS.contains(p.toString())) {
isValid = false;
} else {
isValid = this.fs.getFileStatus(p).isDir();
}
} catch (IOException e) {
LOG.warn(e);
}
return isValid;
}
{noformat}
Could you verify if that code above is like you was thinking?
Thanks.
> printStackTrace in FSUtils
> --
>
> Key: HBASE-6356
> URL: https://issues.apache.org/jira/browse/HBASE-6356
> Project: HBase
> Issue Type: Bug
> Components: Client, master, regionserver
>Affects Versions: 0.96.0
>Reporter: nkeywal
>Priority: Trivial
> Labels: noob
>
> This is bad...
> {noformat}
> public boolean accept(Path p) {
> boolean isValid = false;
> try {
> if (HConstants.HBASE_NON_USER_TABLE_DIRS.contains(p.toString())) {
> isValid = false;
> } else {
> isValid = this.fs.getFileStatus(p).isDir();
> }
> } catch (IOException e) {
> e.printStackTrace(); <
> }
> return isValid;
> }
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490333#comment-13490333 ] Hudson commented on HBASE-7095: --- Integrated in HBase-TRUNK #3513 (See [https://builds.apache.org/job/HBase-TRUNK/3513/]) HBASE-7095 Cannot set 'lenAsVal' for KeyOnlyFilter from shell (Aditya) (Revision 1405657) Result = SUCCESS tedyu : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/filter/KeyOnlyFilter.java > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7089) Allow filter to be specified for Get from HBase shell
[
https://issues.apache.org/jira/browse/HBASE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490334#comment-13490334
]
Hudson commented on HBASE-7089:
---
Integrated in HBase-TRUNK #3513 (See
[https://builds.apache.org/job/HBase-TRUNK/3513/])
HBASE-7089 Allow filter to be specified for Get from HBase shell (Revision
1405640)
Result = SUCCESS
stack :
Files :
* /hbase/trunk/hbase-server/src/main/ruby/hbase/table.rb
* /hbase/trunk/hbase-server/src/main/ruby/shell/commands/get.rb
* /hbase/trunk/hbase-server/src/test/ruby/hbase/table_test.rb
> Allow filter to be specified for Get from HBase shell
> -
>
> Key: HBASE-7089
> URL: https://issues.apache.org/jira/browse/HBASE-7089
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7089_trunk.patch, HBASE-7089_trunk_v2.patch,
> HBASE-7089_trunk_v3.patch, HBASE-7089_trunk_v4.patch
>
>
> Unlike scan, get in HBase shell does not accept FILTER as an argument.
> {noformat}
> hbase(main):001:0> get 'table', 'row3', {FILTER => "ValueFilter (=,
> 'binary:valueX')"}
> COLUMN CELL
> ERROR: Failed parse of {"FILTER"=>"ValueFilter (=, 'binary:valueX')"}, Hash
> Here is some help for this command:
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490338#comment-13490338 ] Lars Hofhansl commented on HBASE-7095: -- This as well as HBASE-7089 seem to be good fixes for 0.94 as well. > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7083) SSH#fixupDaughter should force re-assign missing daughter
[ https://issues.apache.org/jira/browse/HBASE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490340#comment-13490340 ] Lars Hofhansl commented on HBASE-7083: -- Seems like a good fix for 0.94. > SSH#fixupDaughter should force re-assign missing daughter > - > > Key: HBASE-7083 > URL: https://issues.apache.org/jira/browse/HBASE-7083 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Minor > Fix For: 0.96.0 > > Attachments: trunk-7083.patch, trunk-7083.patch > > > In looking into flaky test > TestSplitTransactionOnCluster#testShutdownSimpleFixup, I found out that a > missing daughter is not assigned by SSH properly. It could be open on the > dead server. We need to force re-assign it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490342#comment-13490342 ] Hudson commented on HBASE-7095: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #249 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/249/]) HBASE-7095 Cannot set 'lenAsVal' for KeyOnlyFilter from shell (Aditya) (Revision 1405657) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/filter/KeyOnlyFilter.java > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7089) Allow filter to be specified for Get from HBase shell
[
https://issues.apache.org/jira/browse/HBASE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490343#comment-13490343
]
Hudson commented on HBASE-7089:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #249 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/249/])
HBASE-7089 Allow filter to be specified for Get from HBase shell (Revision
1405640)
Result = FAILURE
stack :
Files :
* /hbase/trunk/hbase-server/src/main/ruby/hbase/table.rb
* /hbase/trunk/hbase-server/src/main/ruby/shell/commands/get.rb
* /hbase/trunk/hbase-server/src/test/ruby/hbase/table_test.rb
> Allow filter to be specified for Get from HBase shell
> -
>
> Key: HBASE-7089
> URL: https://issues.apache.org/jira/browse/HBASE-7089
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7089_trunk.patch, HBASE-7089_trunk_v2.patch,
> HBASE-7089_trunk_v3.patch, HBASE-7089_trunk_v4.patch
>
>
> Unlike scan, get in HBase shell does not accept FILTER as an argument.
> {noformat}
> hbase(main):001:0> get 'table', 'row3', {FILTER => "ValueFilter (=,
> 'binary:valueX')"}
> COLUMN CELL
> ERROR: Failed parse of {"FILTER"=>"ValueFilter (=, 'binary:valueX')"}, Hash
> Here is some help for this command:
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490345#comment-13490345 ] Aditya Kishore commented on HBASE-7095: --- Lars, I agree. The patches should apply easily on 94 branch with -p1. If not, please let me know and I'll attach them (already have them applied on my local 0.94 branch) > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6852) SchemaMetrics.updateOnCacheHit costs too much while full scanning a table with all of its fields
[ https://issues.apache.org/jira/browse/HBASE-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490347#comment-13490347 ] Lars Hofhansl commented on HBASE-6852: -- Yeah... Looks good! Thanks again Cheng. Hey, I was also wondering whether there a chance to do your profiling one more time with HBASE-6032 applied. In your last profiling run here (Oct 7th) HFileBlockIndex$BlockIndexReader.binarySearchNonRootIndex takes the top spot (after this patch). HBASE-6032 was applied on Oct 17th, I'm wondering whether that helped. If you're busy, that's fine too... You already spent a lot of time on this issue. > SchemaMetrics.updateOnCacheHit costs too much while full scanning a table > with all of its fields > > > Key: HBASE-6852 > URL: https://issues.apache.org/jira/browse/HBASE-6852 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 0.94.0 >Reporter: Cheng Hao >Assignee: Cheng Hao >Priority: Minor > Labels: performance > Fix For: 0.94.3 > > Attachments: 6852-0.94_2.patch, 6852-0.94_3.patch, 6852-0.94.txt, > metrics_hotspots.png, onhitcache-trunk.patch > > > The SchemaMetrics.updateOnCacheHit costs too much while I am doing the full > table scanning. > Here is the top 5 hotspots within regionserver while full scanning a table: > (Sorry for the less-well-format) > CPU: Intel Westmere microarchitecture, speed 2.262e+06 MHz (estimated) > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit > mask of 0x00 (No unit mask) count 500 > samples %image name symbol name > --- > 9844713.4324 14033.jo void > org.apache.hadoop.hbase.regionserver.metrics.SchemaMetrics.updateOnCacheHit(org.apache.hadoop.hbase.io.hfile.BlockType$BlockCategory, > boolean) > 98447100.000 14033.jo void > org.apache.hadoop.hbase.regionserver.metrics.SchemaMetrics.updateOnCacheHit(org.apache.hadoop.hbase.io.hfile.BlockType$BlockCategory, > boolean) [self] > --- > 45814 6.2510 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compareRows(byte[], int, int, > byte[], int, int) > 45814100.000 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compareRows(byte[], int, int, > byte[], int, int) [self] > --- > 43523 5.9384 14033.jo boolean > org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(org.apache.hadoop.hbase.KeyValue) > 43523100.000 14033.jo boolean > org.apache.hadoop.hbase.regionserver.StoreFileScanner.reseek(org.apache.hadoop.hbase.KeyValue) > [self] > --- > 42548 5.8054 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compare(byte[], int, int, > byte[], int, int) > 42548100.000 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compare(byte[], int, int, > byte[], int, int) [self] > --- > 40572 5.5358 14033.jo int > org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.binarySearchNonRootIndex(byte[], > int, int, java.nio.ByteBuffer, org.apache.hadoop.io.RawComparator)~1 > 40572100.000 14033.jo int > org.apache.hadoop.hbase.io.hfile.HFileBlockIndex$BlockIndexReader.binarySearchNonRootIndex(byte[], > int, int, java.nio.ByteBuffer, org.apache.hadoop.io.RawComparator)~1 [self] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7095: - Fix Version/s: 0.94.3 > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490348#comment-13490348 ] Lars Hofhansl commented on HBASE-7095: -- Committed to 0.94 as well. Thanks Aditya. > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7089) Allow filter to be specified for Get from HBase shell
[
https://issues.apache.org/jira/browse/HBASE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490354#comment-13490354
]
Lars Hofhansl commented on HBASE-7089:
--
Tried to apply this to 0.94. Patch does not apply cleanly, I futzed around with
it a few minutes.
Table._get_internal and Table._scan_internal do not exist in 0.94.
It's not super important to have this in 0.94. If somebody makes a patch for
0.94, I'll commit it :)
> Allow filter to be specified for Get from HBase shell
> -
>
> Key: HBASE-7089
> URL: https://issues.apache.org/jira/browse/HBASE-7089
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7089_trunk.patch, HBASE-7089_trunk_v2.patch,
> HBASE-7089_trunk_v3.patch, HBASE-7089_trunk_v4.patch
>
>
> Unlike scan, get in HBase shell does not accept FILTER as an argument.
> {noformat}
> hbase(main):001:0> get 'table', 'row3', {FILTER => "ValueFilter (=,
> 'binary:valueX')"}
> COLUMN CELL
> ERROR: Failed parse of {"FILTER"=>"ValueFilter (=, 'binary:valueX')"}, Hash
> Here is some help for this command:
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event
[ https://issues.apache.org/jira/browse/HBASE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490355#comment-13490355 ] Hudson commented on HBASE-5970: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7038 Port HBASE-5970 Improve the AssignmentManager#updateTimer and speed up handling opened event to 0.94 (Sergey Shelukhin) (Revision 1403787) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java > Improve the AssignmentManager#updateTimer and speed up handling opened event > > > Key: HBASE-5970 > URL: https://issues.apache.org/jira/browse/HBASE-5970 > Project: HBase > Issue Type: Improvement > Components: master >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.96.0 > > Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, > HBASE-5970v3.patch, HBASE-5970v4.patch, HBASE-5970v4.patch > > > We found handing opened event very slow in the environment with lots of > regions. > The problem is the slow AssignmentManager#updateTimer. > We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process > of bulk assigning took 1 hours. > 2012-05-06 20:31:49,201 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) round-robin across 5 server(s) > 2012-05-06 21:26:32,103 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done > I think we could do the improvement for the AssignmentManager#updateTimer: > Make a thread do this work. > After the improvement, it took only 4.5mins > 2012-05-07 11:03:36,581 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) across 5 server(s), retainAssignment=true > 2012-05-07 11:07:57,073 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5582) "No HServerInfo found for" should be a WARNING message
[
https://issues.apache.org/jira/browse/HBASE-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490356#comment-13490356
]
Hudson commented on HBASE-5582:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-5582 "No HServerInfo found for" should be a WARNING message (Kevin
Odell via JD) (Revision 1394767)
Result = FAILURE
jdcryans :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/RegionServerTracker.java
> "No HServerInfo found for" should be a WARNING message
> --
>
> Key: HBASE-5582
> URL: https://issues.apache.org/jira/browse/HBASE-5582
> Project: HBase
> Issue Type: Improvement
> Components: master
>Affects Versions: 0.90.4
>Reporter: Shrijeet Paliwal
>Assignee: Kevin Odell
>Priority: Trivial
> Labels: newbie
> Fix For: 0.92.3, 0.94.2, 0.96.0
>
> Attachments: HBASE-5582.patch, HBASE-5582.patch1
>
>
> The message from RegionServerTracker "No HServerInfo found for..." is easy to
> miss. It should not be INFO.
> From irc chat
> {noformat}
> jdcryans
> JohnP789: can you grep for "No HServerInfo found for" in that log?
> jdcryans
> wait I see it
> jdcryans
> ok there's your problem
> shrijeet_
> Yes it is there
> shrijeet_
> jdcryans: it should be INFO, why?
> jdcryans
> it shouldn't be INFO, it's so easy to miss
> jdcryans
> it's not the first time we have to look super closely to figure this one out
> shrijeet_
> yes , I will file a jira
> jdcryans
> in any case it's a mismatch in that machine's DNS config
> shrijeet_
> anyways JohnP789 is waiting :) go on
> JohnP789
> haha!
> JohnP789
> yes... ??? :-)
> jdcryans
> the master is expecting a RS called
> "localhost.localdomain,53875,1328924863478"
> 17:26 jdcryans
> but the RS calls itself "localhost,53875,1328924863478"
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5314) Gracefully rolling restart region servers in rolling-restart.sh
[ https://issues.apache.org/jira/browse/HBASE-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490357#comment-13490357 ] Hudson commented on HBASE-5314: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-5314 Gracefully rolling restart region servers in rolling-restart.sh (Yifeng) (Revision 1401117) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/bin/rolling-restart.sh > Gracefully rolling restart region servers in rolling-restart.sh > --- > > Key: HBASE-5314 > URL: https://issues.apache.org/jira/browse/HBASE-5314 > Project: HBase > Issue Type: Improvement > Components: scripts >Reporter: Yifeng Jiang >Assignee: Yifeng Jiang >Priority: Minor > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-5314-0.94.patch, HBASE-5314.patch, > HBASE-5314.patch.2 > > > The rolling-restart.sh has a --rs-only option which simply restarts all > region servers in the cluster. > Consider improve it to gracefully restart region servers to avoid the offline > time of the regions deployed on that server, and keep the region > distributions same as what it was before the restarting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6312) Make BlockCache eviction thresholds configurable
[ https://issues.apache.org/jira/browse/HBASE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490358#comment-13490358 ] Hudson commented on HBASE-6312: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7053 port blockcache configurability (part of HBASE-6312, and HBASE-7033) to 0.94 (Sergey Shelukhin) (Revision 1402385) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileDataBlockEncoder.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java > Make BlockCache eviction thresholds configurable > > > Key: HBASE-6312 > URL: https://issues.apache.org/jira/browse/HBASE-6312 > Project: HBase > Issue Type: Improvement > Components: io >Affects Versions: 0.94.0 >Reporter: Jie Huang >Assignee: Jie Huang >Priority: Minor > Fix For: 0.96.0 > > Attachments: hbase-6312.patch, hbase-6312_v2.patch, > hbase-6312_v3.patch > > > Some of our customers found that tuning the BlockCache eviction thresholds > made test results different in their test environment. However, those > thresholds are not configurable in the current implementation. The only way > to change those values is to re-compile the HBase source code. We wonder if > it is possible to make them configurable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7051) CheckAndPut should properly read MVCC
[
https://issues.apache.org/jira/browse/HBASE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490359#comment-13490359
]
Hudson commented on HBASE-7051:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> CheckAndPut should properly read MVCC
> -
>
> Key: HBASE-7051
> URL: https://issues.apache.org/jira/browse/HBASE-7051
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: Gregory Chanan
>Assignee: Lars Hofhansl
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7051.txt
>
>
> See, for example:
> {code}
> // TODO: Use MVCC to make this set of increments atomic to reads
> {code}
> Here's an example of what I can happen (would probably be good to write up a
> test case for each read/update):
> Concurrent update via increment and put.
> The put grabs the row lock first and updates the memstore, but releases the
> row lock before the MVCC is advanced. Then, the increment grabs the row lock
> and reads right away, reading the old value and incrementing based on that.
> There are a few options here:
> 1) Waiting for the MVCC to advance for read/updates: the downside is that you
> have to wait for updates on other rows.
> 2) Have an MVCC per-row (table configuration): this avoids the unnecessary
> contention of 1)
> 3) Transform the read/updates to write-only with rollup on read.. E.g. an
> increment would just have the number of values to increment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7017) Backport "[replication] The replication-executor should make sure the file that it is replicating is closed before declaring success on that file" to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490360#comment-13490360 ] Hudson commented on HBASE-7017: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7017 Backport '[replication] The replication-executor should make sure the file that it is replicating is closed before declaring success on that file' to 0.94 (Devaraj Das) (Revision 1404764) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/regionserver/Replication.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Backport "[replication] The replication-executor should make sure the file > that it is replicating is closed before declaring success on that file" to > 0.94 > -- > > Key: HBASE-7017 > URL: https://issues.apache.org/jira/browse/HBASE-7017 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.94.3 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490361#comment-13490361 ] Hudson commented on HBASE-6974: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6974 Metric for blocked updates (Michael Drzal) (Revision 1399881) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerMetrics.java > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: 6974-v5.txt, HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch, HBASE-6974-v4.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7016) port HBASE-6518 'Bytes.toBytesBinary() incorrect trailing backslash escape' to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490362#comment-13490362 ] Hudson commented on HBASE-7016: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7016 port HBASE-6518 'Bytes.toBytesBinary() incorrect trailing backslash escape' to 0.94 (Revision 1401127) Result = FAILURE enis : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/Bytes.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestBytes.java > port HBASE-6518 'Bytes.toBytesBinary() incorrect trailing backslash escape' > to 0.94 > --- > > Key: HBASE-7016 > URL: https://issues.apache.org/jira/browse/HBASE-7016 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Trivial > Fix For: 0.94.3 > > Attachments: HBASE-7016.patch > > > Porting a bugfix... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7053) port blockcache configurability (part of HBASE-6312, and HBASE-7033) to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490363#comment-13490363 ] Hudson commented on HBASE-7053: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7053 port blockcache configurability (part of HBASE-6312, and HBASE-7033) to 0.94 (Sergey Shelukhin) (Revision 1402385) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileDataBlockEncoder.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java > port blockcache configurability (part of HBASE-6312, and HBASE-7033) to 0.94 > - > > Key: HBASE-7053 > URL: https://issues.apache.org/jira/browse/HBASE-7053 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Minor > Fix For: 0.94.3 > > Attachments: HBASE-7053.patch, HBASE-7053-v2-squashed.patch > > > Add an option to get the improvement from 6312 w/o changing the defaults in > stable release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5547) Don't delete HFiles when in "backup mode"
[ https://issues.apache.org/jira/browse/HBASE-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490364#comment-13490364 ] Hudson commented on HBASE-5547: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6796 Backport HBASE-5547, Don't delete HFiles in backup mode. (Jesse Yates) (Revision 1404762) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/BaseConfigurable.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/Chore.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/backup * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/LogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/LogCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/TimeToLiveLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/BaseHFileCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/BaseLogCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/CleanerChore.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/FileCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/HFileCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/LogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/TimeToLiveHFileCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/TimeToLiveLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/master/ReplicationLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/HFileArchiveUtil.java * /hbase/branches/0.94/src/main/resources/hbase-default.xml * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/backup * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestLogsCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestCleanerChore.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestLogsCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/CheckedArchivingHFileCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/HFileArchiveTestingUtil.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestFSTableDescriptors.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestHFileArchiveUtil.java > Don't delete HFiles when in "backup mode" > - > > Key: HBASE-5547 > URL: https://issues.apache.org/jira/browse/HBASE-5547 > Project: HBase > Issue Type: New Feature >Reporter: Lars Hofhansl >Assignee: Jesse Yates > Fix For: 0.96.0 > > Attachments: 5547.addendum-v3, 5547-addendum-v4.txt, 5547-v12.txt, > 5547-v16.txt, hbase-5447-v8.patch, hbase-5447-v8.patch, > hbase-5547-0.94-backport-v0.patch, hbase-5547-v9.patch, > java_HBASE-5547.addendum, java_HBASE-5547.addendum-v1, > java_HBASE-5547.addendum-v2, java_HBASE-5547_v13.patch, > java_HBASE-5547_v14.patch, java_HBASE-5547_v15.patch, > java_HBASE-5547_v4.patch, java_HBASE-5547_v5
[jira] [Commented] (HBASE-7018) Fix and Improve TableDescriptor caching for bulk assignment
[
https://issues.apache.org/jira/browse/HBASE-7018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490365#comment-13490365
]
Hudson commented on HBASE-7018:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7018 Fix and Improve TableDescriptor caching for bulk assignment
(Revision 1401526)
Result = FAILURE
gchanan :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/TableDescriptors.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java
> Fix and Improve TableDescriptor caching for bulk assignment
> ---
>
> Key: HBASE-7018
> URL: https://issues.apache.org/jira/browse/HBASE-7018
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7018-trunk.v2, HBASE-7018-94.patch,
> HBASE-7018-94-v2.patch, HBASE-7018-94-v3.patch, HBASE-7018-trunk.patch,
> HBASE-7018-v3-trunk.patch, HBASE-7018-v4-trunk.patch
>
>
> HBASE-6214 backported HBASE-5998 (Bulk assignment: regionserver optimization
> by using a temporary cache for table descriptors when receiving an open
> regions request), but it's buggy on 0.94 (0.96 appears correct):
> {code}
> HTableDescriptor htd = null;
> if (htds == null) {
> htd = this.tableDescriptors.get(region.getTableName());
> } else {
> htd = htds.get(region.getTableNameAsString());
> if (htd == null) {
> htd = this.tableDescriptors.get(region.getTableName());
> htds.put(region.getRegionNameAsString(), htd);
> }
> }
> {code}
> i.e. we get the tableName from the map but write the regionName.
> Even fixing this, it looks like there are areas for improvement:
> 1) FSTableDescriptors already has a cache (though it goes to the NameNode
> each time through to check we have the latest copy. May as well combine
> these two caches, might be a performance win as well since we don't need to
> write to multiple caches.
> 2) FSTableDescriptors makes two RPCs to the NameNode when it encounters a new
> table. So the total number of RPCs necessary for a bulk assign (without
> caching is):
> #regions + #tables
> (with caching):
> min(#regions,#tables) + #tables = #tables + #tables = 2 * #tables
> We can make this only one RPC, yielding:
> #tables
> Probably not a big deal for most users, but in a multi-tenant situation where
> the number of regions being bulk assigned approaches the number of tables
> being bulk assigned, this could be a nice performance win.
> Benchmarks coming.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6700) [replication] empty znodes created during queue failovers aren't deleted
[
https://issues.apache.org/jira/browse/HBASE-6700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490366#comment-13490366
]
Hudson commented on HBASE-6700:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6700 [replication] empty znodes created during queue failovers aren't
deleted (Terry Zhang via JD) (Revision 1403582)
Result = FAILURE
jdcryans :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/ReplicationZookeeper.java
> [replication] empty znodes created during queue failovers aren't deleted
>
>
> Key: HBASE-6700
> URL: https://issues.apache.org/jira/browse/HBASE-6700
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.94.1
>Reporter: terry zhang
>Assignee: terry zhang
> Fix For: 0.94.3, 0.96.0
>
> Attachments: HBASE-6700.patch
>
>
> Please check code below
> {code:title=ReplicationSourceManager.java|borderStyle=solid}
> // NodeFailoverWorker class
> public void run() {
> {
> ...
> LOG.info("Moving " + rsZnode + "'s hlogs to my queue");
> SortedMap> newQueues =
> zkHelper.copyQueuesFromRS(rsZnode); // Node create here*
> zkHelper.deleteRsQueues(rsZnode);
> if (newQueues == null || newQueues.size() == 0) {
> return;
> }
> ...
> }
> public void closeRecoveredQueue(ReplicationSourceInterface src) {
> LOG.info("Done with the recovered queue " + src.getPeerClusterZnode());
> this.oldsources.remove(src);
> this.zkHelper.deleteSource(src.getPeerClusterZnode(), false); // Node
> delete here*
> }
> {code}
> So from code we can see if newQueues == null or newQueues.size() == 0,
> Failover replication Source will never start and the failover zk node will
> never deleted.
> eg below failover node will never be delete:
> [zk: 10.232.98.77:2181(CONNECTED) 16] ls
> /hbase-test3-repl/replication/rs/dw93.kgb.sqa.cm4,60020,1346337383956/1-dw93.kgb.sqa.cm4,60020,1346309263932-dw91.kgb.sqa.cm4,60020,1346307150041-dw89.kgb.sqa.cm4,60020,1346307911711-dw93.kgb.sqa.cm4,60020,1346312019213-dw88.kgb.sqa.cm4,60020,1346311774939-dw89.kgb.sqa.cm4,60020,1346312314229-dw93.kgb.sqa.cm4,60020,1346312524307-dw88.kgb.sqa.cm4,60020,1346313203367-dw89.kgb.sqa.cm4,60020,1346313944402-dw88.kgb.sqa.cm4,60020,1346314214286-dw91.kgb.sqa.cm4,60020,1346315119613-dw93.kgb.sqa.cm4,60020,1346314186436-dw88.kgb.sqa.cm4,60020,1346315594396-dw89.kgb.sqa.cm4,60020,1346315909491-dw92.kgb.sqa.cm4,60020,1346315315634-dw89.kgb.sqa.cm4,60020,1346316742242-dw93.kgb.sqa.cm4,60020,1346317604055-dw92.kgb.sqa.cm4,60020,1346318098972-dw91.kgb.sqa.cm4,60020,1346317855650-dw93.kgb.sqa.cm4,60020,1346318532530-dw92.kgb.sqa.cm4,60020,1346318573238-dw89.kgb.sqa.cm4,60020,1346321299040-dw91.kgb.sqa.cm4,60020,1346321304393-dw92.kgb.sqa.cm4,60020,1346325755894-dw89.kgb.sqa.cm4,60020,1346326520895-dw91.kgb.sqa.cm4,60020,1346328246992-dw92.kgb.sqa.cm4,60020,1346327290653-dw93.kgb.sqa.cm4,60020,1346337303018-dw91.kgb.sqa.cm4,60020,1346337318929
> [] // empty node will never be deleted
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6978) Minor typo in ReplicationSource SocketTimeoutException error handling
[ https://issues.apache.org/jira/browse/HBASE-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490368#comment-13490368 ] Hudson commented on HBASE-6978: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6978 Minor typo in ReplicationSource SocketTimeoutException error handling (Revision 1397442) Result = FAILURE stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java > Minor typo in ReplicationSource SocketTimeoutException error handling > - > > Key: HBASE-6978 > URL: https://issues.apache.org/jira/browse/HBASE-6978 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 0.92.1, 0.94.2, 0.96.0 >Reporter: Aleksandr Shulman >Assignee: Aleksandr Shulman >Priority: Trivial > Fix For: 0.94.3, 0.96.0 > > Attachments: patch-hbase-6978.patch > > Original Estimate: 5m > Remaining Estimate: 5m > > The user gets an error message on socket timeout exception: > The words "the" and "call" need a space between them. Fix is trivial. > 2012-10-11 11:09:06,154 DEBUG > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: > Encountered a SocketTimeoutException. Since thecall to the remote cluster > timed out, which is usually caused by a machine failure or a massive > slowdown, sleeping 1000 times 100 > The error is present in .92 and onward all the way through to the trunk. Fix > should go into all those branches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490367#comment-13490367 ] Hudson commented on HBASE-7095: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7095 Cannot set 'lenAsVal' for KeyOnlyFilter from shell (Aditya Kishore) (Revision 1405684) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/KeyOnlyFilter.java > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6733) [0.92 UNIT TESTS] TestReplication.queueFailover occasionally fails [Part-2]
[ https://issues.apache.org/jira/browse/HBASE-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490369#comment-13490369 ] Hudson commented on HBASE-6733: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6733 TestReplication.queueFailover occasionally fails [Part-2] (Revision 1401130) Result = FAILURE enis : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java > [0.92 UNIT TESTS] TestReplication.queueFailover occasionally fails [Part-2] > --- > > Key: HBASE-6733 > URL: https://issues.apache.org/jira/browse/HBASE-6733 > Project: HBase > Issue Type: Bug >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.94.3, 0.96.0 > > Attachments: 6733-1.patch, 6733-2.patch, 6733-3.patch, > HBASE-6733-0.94.patch > > > The failure is in TestReplication.queueFailover (fails due to unreplicated > rows). I have come across two problems: > 1. The sleepMultiplier is not properly reset when the currentPath is changed > (in ReplicationSource.java). > 2. ReplicationExecutor sometime removes files to replicate from the queue too > early, resulting in corresponding edits missing. Here the problem is due to > the fact the log-file length that the replication executor finds is not the > most updated one, and hence it doesn't read anything from there, and > ultimately, when there is a log roll, the replication-queue gets a new entry, > and the executor drops the old entry out of the queue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6900) RegionScanner.reseek() creates NPE when a flush or compaction happens before the reseek.
[
https://issues.apache.org/jira/browse/HBASE-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490370#comment-13490370
]
Hudson commented on HBASE-6900:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6900 RegionScanner.reseek() creates NPE when a flush or compaction
happens before the reseek. (Revision 1394378)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java
> RegionScanner.reseek() creates NPE when a flush or compaction happens before
> the reseek.
>
>
> Key: HBASE-6900
> URL: https://issues.apache.org/jira/browse/HBASE-6900
> Project: HBase
> Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 0.94.2, 0.96.0
>
> Attachments: 6900-test.txt, HBASE-6900_1.patch, HBASE-6900.patch
>
>
> HBASE-5520 introduced reseek() on the RegionScanner.
> Now when a scanner is created we have the StoreScanner heap. After this if a
> flush or compaction happens parallely all the StoreScannerObservers are
> cleared so that whenever a new next() call happens we tend to recreate the
> scanner based on the latest store files.
> The reseek() in StoreScanner expects the heap not to be null because always
> reseek would be called from next()
> {code}
> public synchronized boolean reseek(KeyValue kv) throws IOException {
> //Heap cannot be null, because this is only called from next() which
> //guarantees that heap will never be null before this call.
> if (explicitColumnQuery && lazySeekEnabledGlobally) {
> return heap.requestSeek(kv, true, useRowColBloom);
> } else {
> return heap.reseek(kv);
> }
> }
> {code}
> Now when we call RegionScanner.reseek() directly using CPs we tend to get a
> NPE. In our case it happened when a major compaction was going on. I will
> also attach a testcase to show the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6843) loading lzo error when using coprocessor
[ https://issues.apache.org/jira/browse/HBASE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490371#comment-13490371 ] Hudson commented on HBASE-6843: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6843 loading lzo error when using coprocessor (Andy) (Revision 1401550) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorClassLoader.java > loading lzo error when using coprocessor > > > Key: HBASE-6843 > URL: https://issues.apache.org/jira/browse/HBASE-6843 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 0.94.1 >Reporter: Zhou wenjian >Assignee: Zhou wenjian >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6843-trunk.patch > > > After applying HBASE-6308,we found error followed > 2012-09-06 00:44:38,341 DEBUG > org.apache.hadoop.hbase.coprocessor.CoprocessorClassLoader: Finding class: > com.hadoop.compression.lzo.LzoCodec > 2012-09-06 00:44:38,351 ERROR com.hadoop.compression.lzo.GPLNativeCodeLoader: > Could not load native gpl library > java.lang.UnsatisfiedLinkError: Native Library > /home/zhuzhuang/hbase/0.94.0-ali-1.0/lib/native/Linux-amd64-64/libgplcompression.so > already loaded in another classloade > r > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1772) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1732) > at java.lang.Runtime.loadLibrary0(Runtime.java:823) > at java.lang.System.loadLibrary(System.java:1028) > at > com.hadoop.compression.lzo.GPLNativeCodeLoader.(GPLNativeCodeLoader.java:32) > at com.hadoop.compression.lzo.LzoCodec.(LzoCodec.java:67) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:113) > at > org.apache.hadoop.hbase.io.hfile.Compression$Algorithm$1.getCodec(Compression.java:107) > at > org.apache.hadoop.hbase.io.hfile.Compression$Algorithm.getCompressor(Compression.java:243) > at > org.apache.hadoop.hbase.util.CompressionTest.testCompression(CompressionTest.java:85) > at > org.apache.hadoop.hbase.regionserver.HRegion.checkCompressionCodecs(HRegion.java:3793) > at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3782) > at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3732) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:332) > at > org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108) > at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:169) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > 2012-09-06 00:44:38,355 DEBUG > org.apache.hadoop.hbase.coprocessor.CoprocessorClassLoader: Skipping exempt > class java.io.PrintWriter - delegating directly to parent > 2012-09-06 00:44:38,355 ERROR com.hadoop.compression.lzo.LzoCodec: Cannot > load native-lzo without native-hadoop -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6942) Endpoint implementation for bulk deletion of data
[ https://issues.apache.org/jira/browse/HBASE-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490372#comment-13490372 ] Hudson commented on HBASE-6942: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6942 Endpoint implementation for bulk delete rows (Anoop) (Revision 1401332) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/BulkDeleteEndpoint.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/BulkDeleteProtocol.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/BulkDeleteResponse.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestBulkDeleteProtocol.java > Endpoint implementation for bulk deletion of data > - > > Key: HBASE-6942 > URL: https://issues.apache.org/jira/browse/HBASE-6942 > Project: HBase > Issue Type: Improvement > Components: Coprocessors, Performance >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6942_94-V8.patch, HBASE-6942_DeleteTemplate.patch, > HBASE-6942.patch, HBASE-6942_Trunk.patch, HBASE-6942_Trunk-V2.patch, > HBASE-6942_V2.patch, HBASE-6942_V3.patch, HBASE-6942_V4.patch, > HBASE-6942_V5.patch, HBASE-6942_V6.patch, HBASE-6942_V7.patch > > > We can provide an end point implementation for doing a bulk deletion of > data(based on a scan) at the server side. This can reduce the time taken for > such an operation as right now it need to do a scan to client and issue > delete(s) using rowkeys. > Query like delete from table1 where... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6846) BitComparator bug - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490373#comment-13490373
]
Hudson commented on HBASE-6846:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6846 BitComparator bug - ArrayIndexOutOfBoundsException (Lucian
George Iordache) (Revision 1402888)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/BitComparator.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/filter/TestBitComparator.java
> BitComparator bug - ArrayIndexOutOfBoundsException
> --
>
> Key: HBASE-6846
> URL: https://issues.apache.org/jira/browse/HBASE-6846
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 0.94.1
> Environment: HBase 0.94.1 + Hadoop 2.0.0-cdh4.0.1
>Reporter: Lucian George Iordache
>Assignee: Lucian George Iordache
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 6846-trunk.txt, HBASE-6846.patch
>
>
> The HBase 0.94.1 BitComparator introduced a bug in the method "compareTo":
> {code}
> @Override
> public int compareTo(byte[] value, int offset, int length) {
> if (length != this.value.length) {
> return 1;
> }
> int b = 0;
> //Iterating backwards is faster because we can quit after one non-zero
> byte.
> for (int i = value.length - 1; i >= 0 && b == 0; i--) {
> switch (bitOperator) {
> case AND:
> b = (this.value[i] & value[i+offset]) & 0xff;
> break;
> case OR:
> b = (this.value[i] | value[i+offset]) & 0xff;
> break;
> case XOR:
> b = (this.value[i] ^ value[i+offset]) & 0xff;
> break;
> }
> }
> return b == 0 ? 1 : 0;
> }
> {code}
> I've encountered this problem when using a BitComparator with a configured
> this.value.length=8, and in the HBase table there were KeyValues with
> keyValue.getBuffer().length=207911 bytes. In this case:
> {code}
> for (int i = 207910; i >= 0 && b == 0; i--) {
> switch (bitOperator) {
> case AND:
> b = (this.value[207910] ... ==> ArrayIndexOutOfBoundsException
> break;
> {code}
> That loop should use:
> {code}
> for (int i = length - 1; i >= 0 && b == 0; i--) { (or this.value.length.)
> {code}
> Should I provide a patch for correcting the problem?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7048) Regionsplitter requires the hadoop config path to be in hbase classpath
[
https://issues.apache.org/jira/browse/HBASE-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490374#comment-13490374
]
Hudson commented on HBASE-7048:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7048 Regionsplitter requires the hadoop config path to be in hbase
classpath (Ming Ma) (Revision 1402198)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/RegionSplitter.java
> Regionsplitter requires the hadoop config path to be in hbase classpath
> ---
>
> Key: HBASE-7048
> URL: https://issues.apache.org/jira/browse/HBASE-7048
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.2
>Reporter: Ted Yu
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7048-0.94.patch, 7048-trunk.patch
>
>
> When hadoop config path isn't included in hbase classpath, you will get the
> following:
> {code}
> Exception in thread "main" java.lang.IllegalArgumentException: Wrong FS:
> hdfs://t3.e.com/hbase/usertable/_balancedSplit, expected: file:///
> at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:454)
> at
> org.apache.hadoop.fs.RawLocalFileSystem.pathToFile(RawLocalFileSystem.java:67)
> at
> org.apache.hadoop.fs.RawLocalFileSystem.getFileStatus(RawLocalFileSystem.java:431)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:301)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1005)
> at
> org.apache.hadoop.hbase.util.RegionSplitter.getSplits(RegionSplitter.java:643)
> at
> org.apache.hadoop.hbase.util.RegionSplitter.rollingSplit(RegionSplitter.java:367)
> at org.apache.hadoop.hbase.util.RegionSplitter.main(RegionSplitter.java:295)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6904) In the HBase shell, an error is thrown that states replication-related znodes already exist
[ https://issues.apache.org/jira/browse/HBASE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490375#comment-13490375 ] Hudson commented on HBASE-6904: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6904 In the HBase shell, an error is thrown that states replication-related znodes already exist (Revision 1404385) Result = FAILURE gchanan : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/RecoverableZooKeeper.java > In the HBase shell, an error is thrown that states replication-related znodes > already exist > --- > > Key: HBASE-6904 > URL: https://issues.apache.org/jira/browse/HBASE-6904 > Project: HBase > Issue Type: Bug > Components: Replication, Zookeeper >Affects Versions: 0.92.0, 0.92.1, 0.96.0 >Reporter: Aleksandr Shulman >Assignee: Gregory Chanan >Priority: Minor > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6904-94.patch, HBASE-6904.patch > > > On a replication-enabled cluster, querying the list_peers produces the error > lines shown below. It doesn't appear that anything is broken in terms of > functionality. > Stack trace: > hbase(main):001:0> list_peers > 12/09/29 14:41:03 ERROR zookeeper.RecoverableZooKeeper: Node > /hbase/replication/peers already exists and this is not a retry > 12/09/29 14:41:03 ERROR zookeeper.RecoverableZooKeeper: Node > /hbase/replication/rs already exists and this is not a retry > PEER ID CLUSTER KEY > 0 row(s) in 0.4650 seconds -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6032) Port HFileBlockIndex improvement from HBASE-5987
[ https://issues.apache.org/jira/browse/HBASE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490376#comment-13490376 ] Hudson commented on HBASE-6032: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6032 Addendum, forgot to add two files (Revision 1399521) HBASE-6032 Port HFileBlockIndex improvement from HBASE-5987 (Liyin, Ted, Stack) (Revision 1399513) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockWithScanInfo.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestBlocksScanned.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestReseekTo.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestSeekTo.java > Port HFileBlockIndex improvement from HBASE-5987 > > > Key: HBASE-6032 > URL: https://issues.apache.org/jira/browse/HBASE-6032 > Project: HBase > Issue Type: Task >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.94.3, 0.96.0 > > Attachments: 6032.094.txt, 6032-ports-5987.txt, > 6032-ports-5987-v2.txt, 6032v3.txt > > > Excerpt from HBASE-5987: > First, we propose to lookahead for one more block index so that the > HFileScanner would know the start key value of next data block. So if the > target key value for the scan(reSeekTo) is "smaller" than that start kv of > next data block, it means the target key value has a very high possibility in > the current data block (if not in current data block, then the start kv of > next data block should be returned. +Indexing on the start key has some > defects here+) and it shall NOT query the HFileBlockIndex in this case. On > the contrary, if the target key value is "bigger", then it shall query the > HFileBlockIndex. This improvement shall help to reduce the hotness of > HFileBlockIndex and avoid some unnecessary IdLock Contention or Index Block > Cache lookup. > This JIRA is to port the fix to HBase trunk, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7040) Port HBASE-5867 Improve Compaction Throttle Default to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490377#comment-13490377 ] Hudson commented on HBASE-7040: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7040 Port HBASE-5867 Improve Compaction Throttle Default to 0.94 (Sergey Shelukhin) (Revision 1402215) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplitThread.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java > Port HBASE-5867 Improve Compaction Throttle Default to 0.94 > --- > > Key: HBASE-7040 > URL: https://issues.apache.org/jira/browse/HBASE-7040 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Minor > Fix For: 0.94.3 > > Attachments: HBASE-7040.patch > > > Looks like a relatively important (and simple) improvement. Considering > porting to 0.94... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7086) Enhance ResourceChecker to log stack trace for potentially hanging threads
[
https://issues.apache.org/jira/browse/HBASE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490378#comment-13490378
]
Hudson commented on HBASE-7086:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7086 Enhance ResourceChecker to log stack trace for potentially
hanging threads, addendum (Revision 1405207)
HBASE-7086 Enhance ResourceChecker to log stack trace for potentially hanging
threads (Revision 1405081)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/ResourceChecker.java
tedyu :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/ResourceChecker.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/ResourceCheckerJUnitRule.java
> Enhance ResourceChecker to log stack trace for potentially hanging threads
> --
>
> Key: HBASE-7086
> URL: https://issues.apache.org/jira/browse/HBASE-7086
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7086.94, 7086-94.addendum, 7086-trunk.txt,
> 7086-trunk-v2.txt, 7086-trunk-v3.txt, testHFileCleaner.out
>
>
> Currently ResourceChecker logs a line similar to the following if it detects
> potential thread leak:
> {code}
> 2012-11-02 10:18:59,299 INFO [main] hbase.ResourceChecker(157): after
> master.cleaner.TestHFileCleaner#testTTLCleaner: 44 threads (was 43), 145 file
> descriptors (was 145). 0 connections, -thread leak?-
> {code}
> We should enhance the log to include stack trace of the potentially hanging
> thread(s)
> This work was motivated when I investigated test failure in HBASE-6796
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6889) Ignore source control files with apache-rat
[ https://issues.apache.org/jira/browse/HBASE-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490379#comment-13490379 ] Hudson commented on HBASE-6889: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6889 Ignore source control files with apache-rat (Jesse Yates) (Revision 1394736) Result = FAILURE larsh : Files : * /hbase/branches/0.94/pom.xml > Ignore source control files with apache-rat > --- > > Key: HBASE-6889 > URL: https://issues.apache.org/jira/browse/HBASE-6889 > Project: HBase > Issue Type: Bug >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: 0.94.2, 0.96.0 > > Attachments: hbase-6889-mvn-v0.patch > > > Running 'mvn apache-rat:check' locally causes a failure because it finds the > source control files, making it hard to check that you didn't include a file > without a source header. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7087) Add to NOTICE.txt a note on jamon being MPL
[ https://issues.apache.org/jira/browse/HBASE-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490380#comment-13490380 ] Hudson commented on HBASE-7087: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7087 Add to NOTICE.txt a note on jamon being MPL (Revision 1405074) Result = FAILURE stack : Files : * /hbase/branches/0.94/NOTICE.txt > Add to NOTICE.txt a note on jamon being MPL > --- > > Key: HBASE-7087 > URL: https://issues.apache.org/jira/browse/HBASE-7087 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack > Fix For: 0.94.3, 0.96.0 > > Attachments: 7087.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7037) ReplicationPeer logs at WARN level aborting server instead of at FATAL
[ https://issues.apache.org/jira/browse/HBASE-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490382#comment-13490382 ] Hudson commented on HBASE-7037: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7037 ReplicationPeer logs at WARN level aborting server instead of at FATAL (Revision 1401564) Result = FAILURE stack : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeer.java > ReplicationPeer logs at WARN level aborting server instead of at FATAL > -- > > Key: HBASE-7037 > URL: https://issues.apache.org/jira/browse/HBASE-7037 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: stack >Assignee: liang xie > Labels: noob > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7037.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6951) Allow the master info server to be started in a read only mode.
[ https://issues.apache.org/jira/browse/HBASE-6951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490381#comment-13490381 ] Hudson commented on HBASE-6951: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6951 Allow the master info server to be started in a read only mode. (Revision 1400957) Result = FAILURE eclark : Files : * /hbase/branches/0.94/src/main/resources/hbase-webapps/master/table.jsp * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestInfoServers.java > Allow the master info server to be started in a read only mode. > --- > > Key: HBASE-6951 > URL: https://issues.apache.org/jira/browse/HBASE-6951 > Project: HBase > Issue Type: Improvement > Components: UI >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Labels: noob > Fix For: 0.92.3, 0.94.3, 0.96.0 > > Attachments: HBASE-6951-092-0.patch, HBASE-6951-094-0.patch, > HBASE-6951-trunk-0.patch > > > There are some cases that a user could want a web ui to be accessible but > might not want the split and compact functionality to be usable. > Allowing the web ui to start in a readOnly mode would be good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7038) Port HBASE-5970 Improve the AssignmentManager#updateTimer and speed up handling opened event to 0.94
[ https://issues.apache.org/jira/browse/HBASE-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490383#comment-13490383 ] Hudson commented on HBASE-7038: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7038 Port HBASE-5970 Improve the AssignmentManager#updateTimer and speed up handling opened event to 0.94 (Sergey Shelukhin) (Revision 1403787) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java > Port HBASE-5970 Improve the AssignmentManager#updateTimer and speed up > handling opened event to 0.94 > > > Key: HBASE-7038 > URL: https://issues.apache.org/jira/browse/HBASE-7038 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Fix For: 0.94.3 > > Attachments: HBASE-7038.patch > > > This appears to be a major performance improvement. > I will make a 0.94 port patch, please chime in on whether you think it's > reasonable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6336) Split point should not be equal to start row or end row
[
https://issues.apache.org/jira/browse/HBASE-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490384#comment-13490384
]
Hudson commented on HBASE-6336:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7020 Backport HBASE-6336 Split point should not be equal to start row
or end row (Sergey Shelukhin) (Revision 1400359)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
> Split point should not be equal to start row or end row
> ---
>
> Key: HBASE-6336
> URL: https://issues.apache.org/jira/browse/HBASE-6336
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Reporter: chunhui shen
>Assignee: chunhui shen
> Fix For: 0.96.0
>
> Attachments: HBASE-6336.patch
>
>
> Should we allow split point equal with region's start row or end row?
> {code}
> // if the midkey is the same as the first and last keys, then we cannot
> // (ever) split this region.
> if (this.comparator.compareRows(mk, firstKey) == 0 &&
> this.comparator.compareRows(mk, lastKey) == 0) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("cannot split because midkey is the same as first or " +
> "last row");
> }
> {code}
> Here, I think it is a mistake.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7033) Add hbase.lru.blockcache.acceptable.factor to configuration, akin to the min.factor added by HBASE-6312
[ https://issues.apache.org/jira/browse/HBASE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490385#comment-13490385 ] Hudson commented on HBASE-7033: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7053 port blockcache configurability (part of HBASE-6312, and HBASE-7033) to 0.94 (Sergey Shelukhin) (Revision 1402385) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheConfig.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/DoubleBlockCache.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileDataBlockEncoder.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestLruBlockCache.java > Add hbase.lru.blockcache.acceptable.factor to configuration, akin to the > min.factor added by HBASE-6312 > --- > > Key: HBASE-7033 > URL: https://issues.apache.org/jira/browse/HBASE-7033 > Project: HBase > Issue Type: Improvement > Components: io >Affects Versions: 0.96.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Minor > Fix For: 0.96.0 > > Attachments: HBASE-7033.patch > > > Background: we want to make the change to block cache setting available on > 0.94 without actually changing the defaults as was done in HBASE-6312, as > this can be destabilizing. > Thus, both of these would be configurable instead of just one, and the user > would be able to switch to new values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6728) [89-fb] prevent OOM possibility due to per connection responseQueue being unbounded
[ https://issues.apache.org/jira/browse/HBASE-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490386#comment-13490386 ] Hudson commented on HBASE-6728: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6728 prevent OOM possibility due to per connection responseQueue being unbounded (Revision 1401382) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/RegionServerDynamicMetrics.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/SizeBasedThrottler.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestSizeBasedThrottler.java > [89-fb] prevent OOM possibility due to per connection responseQueue being > unbounded > --- > > Key: HBASE-6728 > URL: https://issues.apache.org/jira/browse/HBASE-6728 > Project: HBase > Issue Type: Bug >Reporter: Kannan Muthukkaruppan >Assignee: Michal Gregorczyk > Fix For: 0.94.3 > > Attachments: 6728.94, 6728-trunk.txt > > > The per connection responseQueue is an unbounded queue. The request handler > threads today try to send the response in line, but if things start to > backup, the response is sent via a per connection responder thread. This > intermediate queue, because it has no bounds, can be another source of OOMs. > [Have not looked at this issue in trunk. So it may or may not be applicable > there.] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6996) HRegion.mutateRowsWithLocks should call checkResources/checkReadOnly
[ https://issues.apache.org/jira/browse/HBASE-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490387#comment-13490387 ] Hudson commented on HBASE-6996: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6996 HRegion.mutateRowsWithLocks should call checkResources/checkReadOnl (Revision 1398645) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java > HRegion.mutateRowsWithLocks should call checkResources/checkReadOnly > > > Key: HBASE-6996 > URL: https://issues.apache.org/jira/browse/HBASE-6996 > Project: HBase > Issue Type: Sub-task >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.94.3 > > Attachments: 6996-0.94.txt > > > Turns out that mutateRowsWithLocks does not call check resources, so these > will not get blocked when the memstore gets to large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6853) IllegalArgument Exception is thrown when an empty region is spliitted.
[
https://issues.apache.org/jira/browse/HBASE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490388#comment-13490388
]
Hudson commented on HBASE-6853:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6853 IllegalArgument Exception is thrown when an empty region is
spliitted(Ram) : Addendum for testcase failure (Revision 1396708)
Result = FAILURE
ramkrishna :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
> IllegalArgument Exception is thrown when an empty region is spliitted.
> --
>
> Key: HBASE-6853
> URL: https://issues.apache.org/jira/browse/HBASE-6853
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.1, 0.94.1
>Reporter: ramkrishna.s.vasudevan
>Assignee: Priyadarshini
> Fix For: 0.94.2, 0.96.0
>
> Attachments: HBASE-6853_0.94, HBASE-6853_2_splitsuccess.patch,
> HBASE-6853_addendum.patch, HBASE-6853.patch, HBASE-6853_splitfailure.patch
>
>
> This is w.r.t a mail sent in the dev mail list.
> Empty region split should be handled gracefully. Either we should not allow
> the split to happen if we know that the region is empty or we should allow
> the split to happen by setting the no of threads to the thread pool executor
> as 1.
> {code}
> int nbFiles = hstoreFilesToSplit.size();
> ThreadFactoryBuilder builder = new ThreadFactoryBuilder();
> builder.setNameFormat("StoreFileSplitter-%1$d");
> ThreadFactory factory = builder.build();
> ThreadPoolExecutor threadPool =
> (ThreadPoolExecutor) Executors.newFixedThreadPool(nbFiles, factory);
> List> futures = new ArrayList>(nbFiles);
> {code}
> Here the nbFiles needs to be a non zero positive value.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7077) Test for: CheckAndPut should properly read MVCC
[ https://issues.apache.org/jira/browse/HBASE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490389#comment-13490389 ] Hudson commented on HBASE-7077: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7077 ADDENDUM, add TestCategory (Revision 1404641) HBASE-7077 Test for: CheckAndPut should properly read MVCC (Ram) (Revision 1404383) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHBase7051.java larsh : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHBase7051.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java > Test for: CheckAndPut should properly read MVCC > --- > > Key: HBASE-7077 > URL: https://issues.apache.org/jira/browse/HBASE-7077 > Project: HBase > Issue Type: Sub-task >Reporter: Gregory Chanan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7071.patch, HBASE-7071_testcasewithassert.patch > > > checkAndPut should integrate with MVCC, similar to how HBASE-4583 fixed > appends and increments. > Also need a test, here's one we could use (originally proposed in HBASE-7051): > The current value of some cell is 10. > I issue two concurrent requests: > A) a check and put where check value = 10, put value = 11 > B) a put where put value = 50 > The only result at the end of these operations that seems reasonable to me is > the value of the cell being 50. If A occurred first (ACID wise), then our > values go 10->11->50. If B occurred first, then our values go 10->50 (and the > checkAndPut fails) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5867) Improve Compaction Throttle Default
[ https://issues.apache.org/jira/browse/HBASE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490390#comment-13490390 ] Hudson commented on HBASE-5867: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7040 Port HBASE-5867 Improve Compaction Throttle Default to 0.94 (Sergey Shelukhin) (Revision 1402215) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplitThread.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java > Improve Compaction Throttle Default > --- > > Key: HBASE-5867 > URL: https://issues.apache.org/jira/browse/HBASE-5867 > Project: HBase > Issue Type: Improvement >Reporter: Nicolas Spiegelberg >Assignee: Nicolas Spiegelberg >Priority: Minor > Fix For: 0.96.0 > > Attachments: ASF.LICENSE.NOT.GRANTED--D2943.1.patch, > HBASE-5867-trunk.patch > > > We recently had a production issue where our compactions fell behind because > our compaction throttle was improperly tuned and accidentally upgraded all > compactions to the large pool. The default from HBASE-3877 makes 1 bad > assumption: the default number of flushed files in a compaction. Currently > the algorithm is: > throttleSize ~= flushSize * 2 > This assumes that the basic compaction utilizes 3 files and that all 3 files > are compressed. In this case, "hbase.hstore.compaction.min" == 6 && the > values were not very compressible. Both conditions should be taken into > consideration. As a default, it is less damaging for the large thread to be > slightly higher than it needs to be versus having everything accidentally > promoted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7073) OperationMetrics needs to cache the value of hbase.metrics.exposeOperationTimes
[
https://issues.apache.org/jira/browse/HBASE-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490391#comment-13490391
]
Hudson commented on HBASE-7073:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7073 OperationMetrics needs to cache the value of
hbase.metrics.exposeOperationTimes (Revision 1403865)
Result = FAILURE
eclark :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/OperationMetrics.java
> OperationMetrics needs to cache the value of
> hbase.metrics.exposeOperationTimes
> ---
>
> Key: HBASE-7073
> URL: https://issues.apache.org/jira/browse/HBASE-7073
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.94.2
>Reporter: Jean-Daniel Cryans
>Assignee: Elliott Clark
>Priority: Minor
> Fix For: 0.94.3
>
> Attachments: HBASE-7073-0.patch
>
>
> Trying some increments on my local machine I was surprised to see this in my
> jstacks:
> {noformat}
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.hadoop.conf.Configuration.getProps(Configuration.java:1061)
> - locked <7c4a26430> (a org.apache.hadoop.conf.Configuration)
> at org.apache.hadoop.conf.Configuration.get(Configuration.java:416)
> at
> org.apache.hadoop.hbase.regionserver.CompoundConfiguration$1.get(CompoundConfiguration.java:94)
> at
> org.apache.hadoop.hbase.regionserver.CompoundConfiguration.get(CompoundConfiguration.java:186)
> at
> org.apache.hadoop.hbase.regionserver.CompoundConfiguration.getBoolean(CompoundConfiguration.java:318)
> at
> org.apache.hadoop.hbase.regionserver.metrics.OperationMetrics.doSafeIncTimeVarying(OperationMetrics.java:217)
> at
> org.apache.hadoop.hbase.regionserver.metrics.OperationMetrics.doUpdateTimeVarying(OperationMetrics.java:212)
> at
> org.apache.hadoop.hbase.regionserver.metrics.OperationMetrics.updateIncrementMetrics(OperationMetrics.java:133)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.increment(HRegion.java:4817)
> {noformat}
> It's a pretty horrible lookup that's inline with everything else in that
> class and there's no reason why it shouldn't be a final boolean.
> Assigning this to the master of metrics since he asked for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6852) SchemaMetrics.updateOnCacheHit costs too much while full scanning a table with all of its fields
[ https://issues.apache.org/jira/browse/HBASE-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490392#comment-13490392 ] Hudson commented on HBASE-6852: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6852 RE-REAPPLY, Cheng worked tirelessly to fix the issues. (Revision 1405083) HBASE-6852, REVERT again, due to unexplained test failures that only occur on the jenkins machines (Revision 1404691) HBASE-6852 SchemaMetrics.updateOnCacheHit costs too much while full scanning a table with all of its fields (Cheng Hao and LarsH) - REAPPLY (Revision 1404464) HBASE-6852 REVERT due to test failures. (Revision 1402588) HBASE-6852 SchemaMetrics.updateOnCacheHit costs too much while full scanning a table with all of its fields (Cheng Hao and LarsH) (Revision 1402392) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV1.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/metrics/SchemaMetrics.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/metrics/TestSchemaMetrics.java > SchemaMetrics.updateOnCacheHit costs too much while full scanning a table > with all of its fields > > > Key: HBASE-6852 > URL: https://issues.apache.org/jira/browse/HBASE-6852 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 0.94.0 >Reporter: Cheng Hao >Assignee: Cheng Hao >Priority: Minor > Labels: performance > Fix For: 0.94.3 > > Attachments: 6852-0.94_2.patch, 6852-0.94_3.patch, 6852-0.94.txt, > metrics_hotspots.png, onhitcache-trunk.patch > > > The SchemaMetrics.updateOnCacheHit costs too much while I am doing the full > table scanning. > Here is the top 5 hotspots within regionserver while full scanning a table: > (Sorry for the less-well-format) > CPU: Intel Westmere microarchitecture, speed 2.262e+06 MHz (estimated) > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit > mask of 0x00 (No unit mask) count 500 > samples %image name symbol name > --- > 9844713.4324 14033.jo void > org.apache.hadoop.hbase.regionserver.metrics.SchemaMetrics.updateOnCacheHit(org.apache.hadoop.hbase.io.hfile.BlockType$BlockCategory, > boolean) > 98447100.000 14033.jo void > org.apache.hadoop.hbase.regionserver.metrics.SchemaMetrics.updateOnCacheHit(org.apache.hadoop.hbase.io.hfile.BlockType$BlockCategory, > boolean) [self] > --- > 45814 6.2510 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compareRows(byte[], int, int, > byte[], int, int) > 45814100.000 14033.jo int > org.apache.hadoop.hbase.KeyValue$KeyComparator.compareRows(byte[], int, int, > byte[], int, int) [self] > --
[jira] [Commented] (HBASE-6389) Modify the conditions to ensure that Master waits for sufficient number of Region Servers before starting region assignments
[
https://issues.apache.org/jira/browse/HBASE-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490393#comment-13490393
]
Hudson commented on HBASE-6389:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6389 Modify the conditions to ensure that Master waits for sufficient
number of Region Servers before starting region assignments (Aditya Kishore)
(Revision 1405440)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestRSKilledWhenMasterInitializing.java
> Modify the conditions to ensure that Master waits for sufficient number of
> Region Servers before starting region assignments
>
>
> Key: HBASE-6389
> URL: https://issues.apache.org/jira/browse/HBASE-6389
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Critical
> Fix For: 0.94.3, 0.96.0
>
> Attachments: HBASE-6389_0.94.patch, HBASE-6389_trunk.patch,
> HBASE-6389_trunk.patch, HBASE-6389_trunk.patch, HBASE-6389_trunk_v2.patch,
> HBASE-6389_trunk_v2.patch, org.apache.hadoop.hbase.TestZooKeeper-output.txt,
> testReplication.jstack
>
>
> Continuing from HBASE-6375.
> It seems I was mistaken in my assumption that changing the value of
> "hbase.master.wait.on.regionservers.mintostart" to a sufficient number (from
> default of 1) can help prevent assignment of all regions to one (or a small
> number of) region server(s).
> While this was the case in 0.90.x and 0.92.x, the behavior has changed in
> 0.94.0 onwards to address HBASE-4993.
> From 0.94.0 onwards, Master will proceed immediately after the timeout has
> lapsed, even if "hbase.master.wait.on.regionservers.mintostart" has not
> reached.
> Reading the current conditions of waitForRegionServers() clarifies it
> {code:title=ServerManager.java (trunk rev:1360470)}
>
> 581 /**
> 582 * Wait for the region servers to report in.
> 583 * We will wait until one of this condition is met:
> 584 * - the master is stopped
> 585 * - the 'hbase.master.wait.on.regionservers.timeout' is reached
> 586 * - the 'hbase.master.wait.on.regionservers.maxtostart' number of
> 587 *region servers is reached
> 588 * - the 'hbase.master.wait.on.regionservers.mintostart' is reached
> AND
> 589 * there have been no new region server in for
> 590 * 'hbase.master.wait.on.regionservers.interval' time
> 591 *
> 592 * @throws InterruptedException
> 593 */
> 594 public void waitForRegionServers(MonitoredTask status)
> 595 throws InterruptedException {
>
>
> 612 while (
> 613 !this.master.isStopped() &&
> 614 slept < timeout &&
> 615 count < maxToStart &&
> 616 (lastCountChange+interval > now || count < minToStart)
> 617 ){
>
> {code}
> So with the current conditions, the wait will end as soon as timeout is
> reached even lesser number of RS have checked-in with the Master and the
> master will proceed with the region assignment among these RSes alone.
> As mentioned in
> -[HBASE-4993|https://issues.apache.org/jira/browse/HBASE-4993?focusedCommentId=13237196#comment-13237196]-,
> and I concur, this could have disastrous effect in large cluster especially
> now that MSLAB is turned on.
> To enforce the required quorum as specified by
> "hbase.master.wait.on.regionservers.mintostart" irrespective of timeout,
> these conditions need to be modified as following
> {code:title=ServerManager.java}
> ..
> /**
>* Wait for the region servers to report in.
>* We will wait until one of this condition is met:
>* - the master is stopped
>* - the 'hbase.master.wait.on.regionservers.maxtostart' number of
>*region servers is reached
>* - the 'hbase.master.wait.on.regionservers.mintostart' is reached AND
>* there have been no new region server in for
>* 'hbase.master.wait.on.regionservers.interval' time AND
>* the 'hbase.master.wait.on.regionservers.timeout' is reached
>*
>* @throws InterruptedException
>*/
> public void waitForRegionServers(MonitoredTask status)
> ..
> ..
> int minToStart = this.master.getConfiguration().
> getInt("hbase.master.wait.o
[jira] [Commented] (HBASE-5987) HFileBlockIndex improvement
[ https://issues.apache.org/jira/browse/HBASE-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490394#comment-13490394 ] Hudson commented on HBASE-5987: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6032 Port HFileBlockIndex improvement from HBASE-5987 (Liyin, Ted, Stack) (Revision 1399513) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlockIndex.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestCase.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFileBlockIndex.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestReseekTo.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestSeekTo.java > HFileBlockIndex improvement > --- > > Key: HBASE-5987 > URL: https://issues.apache.org/jira/browse/HBASE-5987 > Project: HBase > Issue Type: Improvement >Reporter: Liyin Tang >Assignee: Liyin Tang > Fix For: 0.96.0 > > Attachments: ASF.LICENSE.NOT.GRANTED--D3237.1.patch, > ASF.LICENSE.NOT.GRANTED--D3237.2.patch, > ASF.LICENSE.NOT.GRANTED--D3237.3.patch, > ASF.LICENSE.NOT.GRANTED--D3237.4.patch, > ASF.LICENSE.NOT.GRANTED--D3237.5.patch, > ASF.LICENSE.NOT.GRANTED--D3237.6.patch, > ASF.LICENSE.NOT.GRANTED--D3237.7.patch, > ASF.LICENSE.NOT.GRANTED--D3237.8.patch, > screen_shot_of_sequential_scan_profiling.png > > > Recently we find out a performance problem that it is quite slow when > multiple requests are reading the same block of data or index. > From the profiling, one of the causes is the IdLock contention which has been > addressed in HBASE-5898. > Another issue is that the HFileScanner will keep asking the HFileBlockIndex > about the data block location for each target key value during the scan > process(reSeekTo), even though the target key value has already been in the > current data block. This issue will cause certain index block very HOT, > especially when it is a sequential scan. > To solve this issue, we propose the following solutions: > First, we propose to lookahead for one more block index so that the > HFileScanner would know the start key value of next data block. So if the > target key value for the scan(reSeekTo) is "smaller" than that start kv of > next data block, it means the target key value has a very high possibility in > the current data block (if not in current data block, then the start kv of > next data block should be returned. +Indexing on the start key has some > defects here+) and it shall NOT query the HFileBlockIndex in this case. On > the contrary, if the target key value is "bigger", then it shall query the > HFileBlockIndex. This improvement shall help to reduce the hotness of > HFileBlockIndex and avoid some unnecessary IdLock Contention or Index Block > Cache lookup. > Secondary, we propose to push this idea a little further that the > HFileBlockIndex shall index on the last key value of each data block instead > of indexing on the start key value. The motivation is to solve the HBASE-4443 > issue (avoid seeking to "previous" block when key you are interested in is > the first one of a block) as well as +the defects mentioned above+. > For example, if the target key value is "smaller" than the start key value of > the data block N. There is no way for sure the target key value is in the > data block N or N-1. So it has to seek from data block N-1. However, if the > block index is based on the last key value for each data block and the target > key value is beween the last key value of data block N-1 and data block N, > then the target key value is supposed be data block N for sure. > As long as HBase only supports the forward scan, the last key value makes > more sense to be indexed on than the start key value. > Thanks Kannan and Mikhail for the insightful discussions and suggestions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6920) On timeout connecting to master, client can get stuck and never make progress
[
https://issues.apache.org/jira/browse/HBASE-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490395#comment-13490395
]
Hudson commented on HBASE-6920:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6920 Addendum2. Remove test code which does not work for the Secure
build (Revision 1395093)
HBASE-6920 Addendum - fix SecureRpcEngine (Revision 1394908)
HBASE-6920 On timeout connecting to master, client can get stuck and never make
progress (Revision 1394857)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/security/src/main/java/org/apache/hadoop/hbase/ipc/SecureRpcEngine.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/RpcEngine.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestClientTimeouts.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/ipc/RandomTimeoutRpcEngine.java
larsh :
Files :
*
/hbase/branches/0.94/security/src/main/java/org/apache/hadoop/hbase/ipc/SecureRpcEngine.java
gchanan :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/RpcEngine.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/WritableRpcEngine.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/client/TestClientTimeouts.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/ipc/RandomTimeoutRpcEngine.java
> On timeout connecting to master, client can get stuck and never make progress
> -
>
> Key: HBASE-6920
> URL: https://issues.apache.org/jira/browse/HBASE-6920
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.2
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Critical
> Fix For: 0.94.2
>
> Attachments: 6920-addendum.txt, HBASE-6920.patch, HBASE-6920-v2.patch
>
>
> HBASE-5058 appears to have introduced an issue where a timeout in
> HConnection.getMaster() can cause the client to never be able to connect to
> the master. So, for example, an HBaseAdmin object can never successfully be
> initialized.
> The issue is here:
> {code}
> if (tryMaster.isMasterRunning()) {
> this.master = tryMaster;
> this.masterLock.notifyAll();
> break;
> }
> {code}
> If isMasterRunning times out, it throws an UndeclaredThrowableException,
> which is already not ideal, because it can be returned to the application.
> But if the first call to getMaster succeeds, it will set masterChecked =
> true, which makes us never try to reconnect; that is, we will set this.master
> = null and just throw MasterNotRunningExceptions, without even trying to
> connect.
> I tried out a 94 client (actually a 92 client with some 94 patches) on a
> cluster with some network issues, and it would constantly get stuck as
> described above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6583) Enhance Hbase load test tool to automatically create column families if not present
[ https://issues.apache.org/jira/browse/HBASE-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490396#comment-13490396 ] Hudson commented on HBASE-6583: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6583. Enhance LoadTestTool to automatically create column families if not present (Sergey Shelukhin) (Revision 1401116) Result = FAILURE apurtell : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/LoadTestTool.java > Enhance Hbase load test tool to automatically create column families if not > present > --- > > Key: HBASE-6583 > URL: https://issues.apache.org/jira/browse/HBASE-6583 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Karthik Ranganathan >Assignee: Sergey Shelukhin > Labels: noob > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6583.patch, HBASE-6583.patch > > > The load test tool currently disables the table and applies any changes to > the cf descriptor if any, but does not create the cf if not present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7069) HTable.batch does not have to synchronized
[ https://issues.apache.org/jira/browse/HBASE-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490397#comment-13490397 ] Hudson commented on HBASE-7069: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7069 (Revision 1403808) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/client/HTable.java > HTable.batch does not have to synchronized > -- > > Key: HBASE-7069 > URL: https://issues.apache.org/jira/browse/HBASE-7069 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Critical > Fix For: 0.94.3 > > Attachments: 7069.txt > > > This was raised on the mailing list by Yousuf. > HTable.batch(...) is synchronized and there appears to be no reason for it. > (flushCommits makes the same call to connection.processBatch and it also is > not synchronized) > This is pretty bad actually marking critical. > 0.96 is fine BTW. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6796) Backport HBASE-5547, Don't delete HFiles in backup mode.
[ https://issues.apache.org/jira/browse/HBASE-6796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490398#comment-13490398 ] Hudson commented on HBASE-6796: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6796 ADDENDUM, remove spurious time limit from testHFileCleaning (Revision 1405275) HBASE-6796 Backport HBASE-5547, Don't delete HFiles in backup mode. (Jesse Yates) (Revision 1404762) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileCleaner.java larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/BaseConfigurable.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/Chore.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/HConstants.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/backup * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/LogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/LogCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/TimeToLiveLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/BaseHFileCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/BaseLogCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/CleanerChore.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/FileCleanerDelegate.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/HFileCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/LogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/TimeToLiveHFileCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/cleaner/TimeToLiveLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLog.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/replication/master/ReplicationLogCleaner.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/FSUtils.java * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/HFileArchiveUtil.java * /hbase/branches/0.94/src/main/resources/hbase-default.xml * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/backup * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestLogsCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestCleanerChore.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestLogsCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/CheckedArchivingHFileCleaner.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/HFileArchiveTestingUtil.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestFSTableDescriptors.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestHFileArchiveUtil.java > Backport HBASE-5547, Don't delete HFiles in backup mode. > > > Key: HBASE-6796 > URL: https://issues.apache.org/jira/browse/HBASE-6796 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Jesse Yates > Fix For: 0.94.3 > > Attachments: hbase-5547-0.94-backport-v0.patch, hbase-6796-v0.patch, > hbase-6796-v1.patch, hbase-6796-v2.patch > > > See HBASE-5547 -- This message is automatically generat
[jira] [Commented] (HBASE-6925) Change socket write size from 8K to 64K for HBaseServer
[ https://issues.apache.org/jira/browse/HBASE-6925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490399#comment-13490399 ] Hudson commented on HBASE-6925: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-6925 Change socket write size from 8K to 64K for HBaseServer (Karthik) (Revision 1404776) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java > Change socket write size from 8K to 64K for HBaseServer > --- > > Key: HBASE-6925 > URL: https://issues.apache.org/jira/browse/HBASE-6925 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: Karthik Ranganathan >Assignee: Karthik Ranganathan >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6925.patch > > > Creating a JIRA for this, but the change is trivial: change NIO_BUFFER_LIMIT > from 8K to 64K in HBaseServer. This seems to increase scan throughput. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6305) TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
[
https://issues.apache.org/jira/browse/HBASE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490400#comment-13490400
]
Hudson commented on HBASE-6305:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-6305 TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
(Himanshu) (Revision 1405286)
Result = FAILURE
larsh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestLocalHBaseCluster.java
> TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
>
>
> Key: HBASE-6305
> URL: https://issues.apache.org/jira/browse/HBASE-6305
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 0.92.2, 0.94.1
>Reporter: Jonathan Hsieh
>Assignee: Himanshu Vashishtha
> Fix For: 0.94.3
>
> Attachments: hbase-6305-94.patch, HBASE-6305-94-v2.patch,
> HBASE-6305-94-v2.patch, HBASE-6305-v1.patch
>
>
> trunk: mvn clean test -Dhadoop.profile=2.0 -Dtest=TestLocalHBaseCluster
> 0.94: mvn clean test -Dhadoop.profile=23 -Dtest=TestLocalHBaseCluster
> {code}
> testLocalHBaseCluster(org.apache.hadoop.hbase.TestLocalHBaseCluster) Time
> elapsed: 0.022 sec <<< ERROR!
> java.lang.RuntimeException: Master not initialized after 200 seconds
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:208)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:424)
> at
> org.apache.hadoop.hbase.TestLocalHBaseCluster.testLocalHBaseCluster(TestLocalHBaseCluster.java:66)
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7060) Region load balancing by table does not handle the case where a table's region count is lower than the number of the RS in the cluster
[
https://issues.apache.org/jira/browse/HBASE-7060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490401#comment-13490401
]
Hudson commented on HBASE-7060:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-7060 Region load balancing by table does not handle the case where a
table's region count is lower than the number of the RS in the cluster (Ted Yu
and Tianying) (Revision 1403801)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/DefaultLoadBalancer.java
> Region load balancing by table does not handle the case where a table's
> region count is lower than the number of the RS in the cluster
> --
>
> Key: HBASE-7060
> URL: https://issues.apache.org/jira/browse/HBASE-7060
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.92.0
>Reporter: Tianying Chang
>Assignee: Ted Yu
> Fix For: 0.94.3, 0.96.0
>
> Attachments: 7060-94.txt, 7060-94-v2.txt, 7060-test-tentative-94.txt,
> 7060-trunk.txt, HBASE-7060.patch
>
>
> When the table's region count is less than the count of region servers, the
> region balance algorithm will not move the region. For example, the cluster
> has 100 RS, the table has 50 regions sitting on one RS, they will not be
> moved to any of the other 99 RS.
> This is because the algorithm did not calculate the under-loaded RS
> correctly. This is how the algorithm works with the above example:
> avg-regions-per-RS=0.5
> min-RS-per-RS=0
> max-RS-per-RS=1
> when they calculate the under loaded RS, the code is as below. Since
> regionCount=0, which is always >=min, so it will always skip, therefore, no
> underloaded RS are found.
> Map underloadedServers = new HashMap Integer>();
> for (Map.Entry> server:
> serversByLoad.entrySet()) {
> int regionCount = server.getKey().getLoad();
> if (regionCount >= min) { break; }
> underloadedServers.put(server.getKey().getServerName(), min - regionCount);
> }
> Later the function returns since underloaded RS size is 0
> if (serverUnerloaded ==0) return regionsToReturn;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5257) Allow INCLUDE_AND_NEXT_COL in filters and use it in ColumnPaginationFilter
[
https://issues.apache.org/jira/browse/HBASE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490402#comment-13490402
]
Hudson commented on HBASE-5257:
---
Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See
[https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/])
HBASE-5257 Allow INCLUDE_AND_NEXT_COL in filters and use it in
ColumnPaginationFilter (Varun) (Revision 1402210)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/ColumnCountGetFilter.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/ColumnPaginationFilter.java
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/Filter.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/filter/TestColumnPaginationFilter.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/filter/TestFilter.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> Allow INCLUDE_AND_NEXT_COL in filters and use it in ColumnPaginationFilter
> --
>
> Key: HBASE-5257
> URL: https://issues.apache.org/jira/browse/HBASE-5257
> Project: HBase
> Issue Type: Improvement
>Reporter: Lars Hofhansl
>Assignee: Varun Sharma
> Fix For: 0.92.3, 0.94.3, 0.96.0
>
> Attachments: 5257-0.92.addendum, 5257-trunk.txt, 5257-trunk-v2.txt,
> HBASE-5257-0.92.txt, HBASE-5257-0.94.txt
>
>
> There are various usecases and filter types where evaluating the filter
> before version are handled either do not make sense, or make filter handling
> more complicated.
> Also see this comment in ScanQueryMatcher:
> {code}
> /**
> * Filters should be checked before checking column trackers. If we do
> * otherwise, as was previously being done, ColumnTracker may increment
> its
> * counter for even that KV which may be discarded later on by Filter.
> This
> * would lead to incorrect results in certain cases.
> */
> {code}
> So we had Filters after the column trackers (which do the version checking),
> and then moved it.
> Should be at the discretion of the Filter.
> Could either add a new method to FilterBase (maybe excludeVersions() or
> something). Or have a new Filter wrapper (like WhileMatchFilter), that should
> only be used as outmost filter and indicates the same (maybe
> ExcludeVersionsFilter).
> See latest comments on HBASE-5229 for motivation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7021) Default to Hadoop 1.0.4 in 0.94 and add Hadoop 1.1 profile
[ https://issues.apache.org/jira/browse/HBASE-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490403#comment-13490403 ] Hudson commented on HBASE-7021: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7021 Default to Hadoop 1.0.4 in 0.94 and add Hadoop 1.1 profile (Revision 1400366) Result = FAILURE larsh : Files : * /hbase/branches/0.94/pom.xml > Default to Hadoop 1.0.4 in 0.94 and add Hadoop 1.1 profile > -- > > Key: HBASE-7021 > URL: https://issues.apache.org/jira/browse/HBASE-7021 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.94.3 > > Attachments: 7021.txt, 7021-v2.txt > > > Hadoop 1.0.4 was released, we should default to that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7020) Backport HBASE-6336 Split point should not be equal to start row or end row
[ https://issues.apache.org/jira/browse/HBASE-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490404#comment-13490404 ] Hudson commented on HBASE-7020: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7020 Backport HBASE-6336 Split point should not be equal to start row or end row (Sergey Shelukhin) (Revision 1400359) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java > Backport HBASE-6336 Split point should not be equal to start row or end row > --- > > Key: HBASE-7020 > URL: https://issues.apache.org/jira/browse/HBASE-7020 > Project: HBase > Issue Type: Task >Affects Versions: 0.94.2 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Fix For: 0.94.3 > > Attachments: HBASE-7020.patch > > > Backport a bugfix. Separate JIRA as per the comment in original JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6518) Bytes.toBytesBinary() incorrect trailing backslash escape
[ https://issues.apache.org/jira/browse/HBASE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490405#comment-13490405 ] Hudson commented on HBASE-6518: --- Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/]) HBASE-7016 port HBASE-6518 'Bytes.toBytesBinary() incorrect trailing backslash escape' to 0.94 (Revision 1401127) Result = FAILURE enis : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/Bytes.java * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/util/TestBytes.java > Bytes.toBytesBinary() incorrect trailing backslash escape > - > > Key: HBASE-6518 > URL: https://issues.apache.org/jira/browse/HBASE-6518 > Project: HBase > Issue Type: Bug > Components: util >Reporter: Tudor Scurtu >Assignee: Tudor Scurtu >Priority: Trivial > Labels: patch > Fix For: 0.96.0 > > Attachments: HBASE-6518.patch > > > Bytes.toBytesBinary() converts escaped strings to byte arrays. When > encountering a '\' character, it looks at the next one to see if it is an > 'x', without checking if it exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6389) Modify the conditions to ensure that Master waits for sufficient number of Region Servers before starting region assignments
[
https://issues.apache.org/jira/browse/HBASE-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490410#comment-13490410
]
Hudson commented on HBASE-6389:
---
Integrated in HBase-0.94-security #82 (See
[https://builds.apache.org/job/HBase-0.94-security/82/])
HBASE-6389 Modify the conditions to ensure that Master waits for sufficient
number of Region Servers before starting region assignments (Aditya Kishore)
(Revision 1405440)
Result = SUCCESS
larsh :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/master/TestMasterFailover.java
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/TestRSKilledWhenMasterInitializing.java
> Modify the conditions to ensure that Master waits for sufficient number of
> Region Servers before starting region assignments
>
>
> Key: HBASE-6389
> URL: https://issues.apache.org/jira/browse/HBASE-6389
> Project: HBase
> Issue Type: Bug
> Components: master
>Affects Versions: 0.94.0, 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Critical
> Fix For: 0.94.3, 0.96.0
>
> Attachments: HBASE-6389_0.94.patch, HBASE-6389_trunk.patch,
> HBASE-6389_trunk.patch, HBASE-6389_trunk.patch, HBASE-6389_trunk_v2.patch,
> HBASE-6389_trunk_v2.patch, org.apache.hadoop.hbase.TestZooKeeper-output.txt,
> testReplication.jstack
>
>
> Continuing from HBASE-6375.
> It seems I was mistaken in my assumption that changing the value of
> "hbase.master.wait.on.regionservers.mintostart" to a sufficient number (from
> default of 1) can help prevent assignment of all regions to one (or a small
> number of) region server(s).
> While this was the case in 0.90.x and 0.92.x, the behavior has changed in
> 0.94.0 onwards to address HBASE-4993.
> From 0.94.0 onwards, Master will proceed immediately after the timeout has
> lapsed, even if "hbase.master.wait.on.regionservers.mintostart" has not
> reached.
> Reading the current conditions of waitForRegionServers() clarifies it
> {code:title=ServerManager.java (trunk rev:1360470)}
>
> 581 /**
> 582 * Wait for the region servers to report in.
> 583 * We will wait until one of this condition is met:
> 584 * - the master is stopped
> 585 * - the 'hbase.master.wait.on.regionservers.timeout' is reached
> 586 * - the 'hbase.master.wait.on.regionservers.maxtostart' number of
> 587 *region servers is reached
> 588 * - the 'hbase.master.wait.on.regionservers.mintostart' is reached
> AND
> 589 * there have been no new region server in for
> 590 * 'hbase.master.wait.on.regionservers.interval' time
> 591 *
> 592 * @throws InterruptedException
> 593 */
> 594 public void waitForRegionServers(MonitoredTask status)
> 595 throws InterruptedException {
>
>
> 612 while (
> 613 !this.master.isStopped() &&
> 614 slept < timeout &&
> 615 count < maxToStart &&
> 616 (lastCountChange+interval > now || count < minToStart)
> 617 ){
>
> {code}
> So with the current conditions, the wait will end as soon as timeout is
> reached even lesser number of RS have checked-in with the Master and the
> master will proceed with the region assignment among these RSes alone.
> As mentioned in
> -[HBASE-4993|https://issues.apache.org/jira/browse/HBASE-4993?focusedCommentId=13237196#comment-13237196]-,
> and I concur, this could have disastrous effect in large cluster especially
> now that MSLAB is turned on.
> To enforce the required quorum as specified by
> "hbase.master.wait.on.regionservers.mintostart" irrespective of timeout,
> these conditions need to be modified as following
> {code:title=ServerManager.java}
> ..
> /**
>* Wait for the region servers to report in.
>* We will wait until one of this condition is met:
>* - the master is stopped
>* - the 'hbase.master.wait.on.regionservers.maxtostart' number of
>*region servers is reached
>* - the 'hbase.master.wait.on.regionservers.mintostart' is reached AND
>* there have been no new region server in for
>* 'hbase.master.wait.on.regionservers.interval' time AND
>* the 'hbase.master.wait.on.regionservers.timeout' is reached
>*
>* @throws InterruptedException
>*/
> public void waitForRegionServers(MonitoredTask status)
> ..
> ..
> int minToStart = this.master.getConfiguration().
> getInt("hbase.master.wait.on.regionservers.mintosta
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490411#comment-13490411 ] Hudson commented on HBASE-7095: --- Integrated in HBase-0.94-security #82 (See [https://builds.apache.org/job/HBase-0.94-security/82/]) HBASE-7095 Cannot set 'lenAsVal' for KeyOnlyFilter from shell (Aditya Kishore) (Revision 1405684) Result = SUCCESS larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/KeyOnlyFilter.java > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6305) TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
[
https://issues.apache.org/jira/browse/HBASE-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490412#comment-13490412
]
Hudson commented on HBASE-6305:
---
Integrated in HBase-0.94-security #82 (See
[https://builds.apache.org/job/HBase-0.94-security/82/])
HBASE-6305 TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
(Himanshu) (Revision 1405286)
Result = SUCCESS
larsh :
Files :
*
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/TestLocalHBaseCluster.java
> TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
>
>
> Key: HBASE-6305
> URL: https://issues.apache.org/jira/browse/HBASE-6305
> Project: HBase
> Issue Type: Sub-task
> Components: test
>Affects Versions: 0.92.2, 0.94.1
>Reporter: Jonathan Hsieh
>Assignee: Himanshu Vashishtha
> Fix For: 0.94.3
>
> Attachments: hbase-6305-94.patch, HBASE-6305-94-v2.patch,
> HBASE-6305-94-v2.patch, HBASE-6305-v1.patch
>
>
> trunk: mvn clean test -Dhadoop.profile=2.0 -Dtest=TestLocalHBaseCluster
> 0.94: mvn clean test -Dhadoop.profile=23 -Dtest=TestLocalHBaseCluster
> {code}
> testLocalHBaseCluster(org.apache.hadoop.hbase.TestLocalHBaseCluster) Time
> elapsed: 0.022 sec <<< ERROR!
> java.lang.RuntimeException: Master not initialized after 200 seconds
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:208)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:424)
> at
> org.apache.hadoop.hbase.TestLocalHBaseCluster.testLocalHBaseCluster(TestLocalHBaseCluster.java:66)
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event
[ https://issues.apache.org/jira/browse/HBASE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490414#comment-13490414 ] chunhui shen commented on HBASE-5970: - [~yangming] Please see the HBASE-7018, you know why your cluster handle opened event slow. In my testing, the cluster doesn't have the problem by HBASE-7018, so its bottleneck is on the master. Also, please increase the open region threads on the regionserver. If you also have problem, you could email me directly... > Improve the AssignmentManager#updateTimer and speed up handling opened event > > > Key: HBASE-5970 > URL: https://issues.apache.org/jira/browse/HBASE-5970 > Project: HBase > Issue Type: Improvement > Components: master >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.96.0 > > Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, > HBASE-5970v3.patch, HBASE-5970v4.patch, HBASE-5970v4.patch > > > We found handing opened event very slow in the environment with lots of > regions. > The problem is the slow AssignmentManager#updateTimer. > We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process > of bulk assigning took 1 hours. > 2012-05-06 20:31:49,201 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) round-robin across 5 server(s) > 2012-05-06 21:26:32,103 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done > I think we could do the improvement for the AssignmentManager#updateTimer: > Make a thread do this work. > After the improvement, it took only 4.5mins > 2012-05-07 11:03:36,581 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) across 5 server(s), retainAssignment=true > 2012-05-07 11:07:57,073 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7089) Allow filter to be specified for Get from HBase shell
[
https://issues.apache.org/jira/browse/HBASE-7089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aditya Kishore updated HBASE-7089:
--
Attachment: HBASE-7089_94.patch
Oh forgot about the function rename! Here is the one for 0.94 branch.
> Allow filter to be specified for Get from HBase shell
> -
>
> Key: HBASE-7089
> URL: https://issues.apache.org/jira/browse/HBASE-7089
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0
>Reporter: Aditya Kishore
>Assignee: Aditya Kishore
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7089_94.patch, HBASE-7089_trunk.patch,
> HBASE-7089_trunk_v2.patch, HBASE-7089_trunk_v3.patch,
> HBASE-7089_trunk_v4.patch
>
>
> Unlike scan, get in HBase shell does not accept FILTER as an argument.
> {noformat}
> hbase(main):001:0> get 'table', 'row3', {FILTER => "ValueFilter (=,
> 'binary:valueX')"}
> COLUMN CELL
> ERROR: Failed parse of {"FILTER"=>"ValueFilter (=, 'binary:valueX')"}, Hash
> Here is some help for this command:
> ...
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5970) Improve the AssignmentManager#updateTimer and speed up handling opened event
[ https://issues.apache.org/jira/browse/HBASE-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490420#comment-13490420 ] yang ming commented on HBASE-5970: -- [~zjushch] ok,thanks very much! I will try! > Improve the AssignmentManager#updateTimer and speed up handling opened event > > > Key: HBASE-5970 > URL: https://issues.apache.org/jira/browse/HBASE-5970 > Project: HBase > Issue Type: Improvement > Components: master >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.96.0 > > Attachments: 5970v3.patch, HBASE-5970.patch, HBASE-5970v2.patch, > HBASE-5970v3.patch, HBASE-5970v4.patch, HBASE-5970v4.patch > > > We found handing opened event very slow in the environment with lots of > regions. > The problem is the slow AssignmentManager#updateTimer. > We do the test for bulk assigning 10w (i.e. 100k) regions, the whole process > of bulk assigning took 1 hours. > 2012-05-06 20:31:49,201 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) round-robin across 5 server(s) > 2012-05-06 21:26:32,103 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done > I think we could do the improvement for the AssignmentManager#updateTimer: > Make a thread do this work. > After the improvement, it took only 4.5mins > 2012-05-07 11:03:36,581 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning 10 > region(s) across 5 server(s), retainAssignment=true > 2012-05-07 11:07:57,073 INFO > org.apache.hadoop.hbase.master.AssignmentManager: Bulk assigning done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7095) Cannot set 'lenAsVal' for KeyOnlyFilter from shell
[ https://issues.apache.org/jira/browse/HBASE-7095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490422#comment-13490422 ] Hudson commented on HBASE-7095: --- Integrated in HBase-0.94 #572 (See [https://builds.apache.org/job/HBase-0.94/572/]) HBASE-7095 Cannot set 'lenAsVal' for KeyOnlyFilter from shell (Aditya Kishore) (Revision 1405684) Result = FAILURE larsh : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/filter/KeyOnlyFilter.java > Cannot set 'lenAsVal' for KeyOnlyFilter from shell > -- > > Key: HBASE-7095 > URL: https://issues.apache.org/jira/browse/HBASE-7095 > Project: HBase > Issue Type: Bug > Components: Filters >Affects Versions: 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: shell > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-7095_trunk.patch > > > Current implementation of createFilterFromArguments() in KeyOnlyFilter > rejects the Boolean argument, effectively preventing from specifying this > option from HBase shell. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5257) Allow INCLUDE_AND_NEXT_COL in filters and use it in ColumnPaginationFilter
[
https://issues.apache.org/jira/browse/HBASE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490436#comment-13490436
]
Hudson commented on HBASE-5257:
---
Integrated in HBase-0.92-security #146 (See
[https://builds.apache.org/job/HBase-0.92-security/146/])
HBASE-5257 Addendum fixes typo in ColumnCountGetFilter.java (Revision
1402225)
HBASE-5257 Allow INCLUDE_AND_NEXT_COL in filters and use it in
ColumnPaginationFilter (Varun) (Revision 1402211)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/filter/ColumnCountGetFilter.java
tedyu :
Files :
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/filter/ColumnCountGetFilter.java
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/filter/ColumnPaginationFilter.java
* /hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/filter/Filter.java
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
*
/hbase/branches/0.92/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java
*
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/filter/TestColumnPaginationFilter.java
*
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/filter/TestFilter.java
*
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> Allow INCLUDE_AND_NEXT_COL in filters and use it in ColumnPaginationFilter
> --
>
> Key: HBASE-5257
> URL: https://issues.apache.org/jira/browse/HBASE-5257
> Project: HBase
> Issue Type: Improvement
>Reporter: Lars Hofhansl
>Assignee: Varun Sharma
> Fix For: 0.92.3, 0.94.3, 0.96.0
>
> Attachments: 5257-0.92.addendum, 5257-trunk.txt, 5257-trunk-v2.txt,
> HBASE-5257-0.92.txt, HBASE-5257-0.94.txt
>
>
> There are various usecases and filter types where evaluating the filter
> before version are handled either do not make sense, or make filter handling
> more complicated.
> Also see this comment in ScanQueryMatcher:
> {code}
> /**
> * Filters should be checked before checking column trackers. If we do
> * otherwise, as was previously being done, ColumnTracker may increment
> its
> * counter for even that KV which may be discarded later on by Filter.
> This
> * would lead to incorrect results in certain cases.
> */
> {code}
> So we had Filters after the column trackers (which do the version checking),
> and then moved it.
> Should be at the discretion of the Filter.
> Could either add a new method to FilterBase (maybe excludeVersions() or
> something). Or have a new Filter wrapper (like WhileMatchFilter), that should
> only be used as outmost filter and indicates the same (maybe
> ExcludeVersionsFilter).
> See latest comments on HBASE-5229 for motivation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
