[jira] [Commented] (HBASE-9278) Reading Pre-namespace meta table edits kills the reader
[
https://issues.apache.org/jira/browse/HBASE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751024#comment-13751024
]
Hadoop QA commented on HBASE-9278:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600088/HBase-9278-v1-1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6920//console
This message is automatically generated.
> Reading Pre-namespace meta table edits kills the reader
> ---
>
> Key: HBASE-9278
> URL: https://issues.apache.org/jira/browse/HBASE-9278
> Project: HBase
> Issue Type: Bug
> Components: migration, wal
>Affects Versions: 0.95.2
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBase-9278-v0.patch, HBase-9278-v1-1.patch,
> HBase-9278-v1.patch
>
>
> In upgrading to 0.96, there might be some meta/root table edits. Currently,
> we are just killing SplitLogWorker thread in case it sees any META, or ROOT
> waledit, which blocks log splitting/replaying of remaining WALs.
> {code}
> 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker
> (SplitLogWorker.java:run(210)) - unexpected error
> java.lang.IllegalArgumentException: .META. no longer exists. The table has
> been renamed to hbase:meta
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
> at
> org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplit
[jira] [Updated] (HBASE-9230) Fix the server so it can take a pure pb request param and return a pure pb result
[ https://issues.apache.org/jira/browse/HBASE-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-9230: - Summary: Fix the server so it can take a pure pb request param and return a pure pb result (was: Fix the server so it can take a pure pb request param and return a pure pb resutl) > Fix the server so it can take a pure pb request param and return a pure pb > result > - > > Key: HBASE-9230 > URL: https://issues.apache.org/jira/browse/HBASE-9230 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Critical > Fix For: 0.96.0 > > > Working on the asynchbase update w/ B this afternoon so it can run against > 0.95/0.96, I noticed that clients HAVE TO do cellblocks as the server is > currently. That is an oversight. Lets fix so can do all pb all the time too > (I thought this was there but it is not); it will make it easier dev'ing > simple clients. > This issue shouldn't hold up release but we should get it in to help the > asynchbase convertion. -- 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-9321) Contention getting the current user in RpcClient$Connection.writeRequest
[
https://issues.apache.org/jira/browse/HBASE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751018#comment-13751018
]
Devaraj Das commented on HBASE-9321:
bq. If one connection per user, we may have many connections if there are many
users.
I would not be worried about supporting 100s of users each with their own
separate connection, from the REST server (assuming modest configuration of the
system). I'd suggest to start with, to reuse connections for the same user. If
you ask oozie folks, they will tell you about a cache they implemented in their
layer to deal with the many users problem (in their case they ended up creating
too many filesystem instances even for the same enduser). The cache is from
user -> ProxyUGI, right [~tucu00]?
I believe Hadoop core has done (or is doing) work to reuse connections for
multiple users (not sure whether the proxy users have been covered there).
I am +1 for both caching the "realuser" UGI and reusing connections across
different proxy-users for the same realuser within the RPC layer. Maybe, a good
one for 0.98?
> Contention getting the current user in RpcClient$Connection.writeRequest
>
>
> Key: HBASE-9321
> URL: https://issues.apache.org/jira/browse/HBASE-9321
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Jean-Daniel Cryans
> Fix For: 0.98.0, 0.96.0
>
> Attachments: trunk-9321.patch
>
>
> I've been running tests on clusters with "lots" of regions, about 400, and
> I'm seeing weird contention in the client.
> This one I see a lot, hundreds and sometimes thousands of threads are blocked
> like this:
> {noformat}
> "htable-pool4-t74" daemon prio=10 tid=0x7f2254114000 nid=0x2a99 waiting
> for monitor entry [0x7f21f9e94000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:466)
> - waiting to lock <0xfb5ad000> (a java.lang.Class for
> org.apache.hadoop.security.UserGroupInformation)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.writeRequest(RpcClient.java:1013)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1407)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1634)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1691)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.multi(ClientProtos.java:27339)
> at
> org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:105)
> at
> org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:43)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:183)
> {noformat}
> While the holder is doing this:
> {noformat}
> "htable-pool17-t55" daemon prio=10 tid=0x7f2244408000 nid=0x2a98 runnable
> [0x7f21f9f95000]
>java.lang.Thread.State: RUNNABLE
> at java.security.AccessController.getStackAccessControlContext(Native
> Method)
> at java.security.AccessController.getContext(AccessController.java:487)
> at
> org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:466)
> - locked <0xfb5ad000> (a java.lang.Class for
> org.apache.hadoop.security.UserGroupInformation)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.writeRequest(RpcClient.java:1013)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1407)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1634)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1691)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.multi(ClientProtos.java:27339)
> at
> org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:105)
> at
> org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:43)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:183)
> {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] [Updated] (HBASE-9116) Add a view/edit tool for favored node mappings for regions
[ https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-9116: --- Attachment: 9116-6.txt The patch with the findbugs warnings taken care of, and one of Nick's comment addressed. > Add a view/edit tool for favored node mappings for regions > -- > > Key: HBASE-9116 > URL: https://issues.apache.org/jira/browse/HBASE-9116 > Project: HBase > Issue Type: Improvement > Components: Region Assignment >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.96.0 > > Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, > 9116-3.txt, 9116-4.txt, 9116-5.txt, 9116-6.txt > > > Add a tool that one can run offline to view the favored node mappings for > regions, and also fix the mappings if needed. Such a tool exists in the > 0.89-fb branch. Will port it over to trunk/0.95. -- 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-9116) Add a view/edit tool for favored node mappings for regions
[ https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750997#comment-13750997 ] Devaraj Das commented on HBASE-9116: bq. Why not just call initialize() at the end of the constructor body? The reason being I wanted to keep the construction of the object cheap. The initialization does some IO since it scans the meta, and I wanted to keep this out of the basic constructor... bq. Is it worth RegionPlacementMaintainer extending AbstractHBaseTool? IMHO this is not going to add that much value. Do you mind if I look at this in a follow up. bq. Is this necessary – can you instead separate out "case 2" as a second test? -@Test(timeout = 18) +@Test(timeout = 180) Fixed the timeout (that was a good catch). The reason the test is clubbed into one is that the test tries out the various favorednode utilities with a single table that it creates in the beginning. > Add a view/edit tool for favored node mappings for regions > -- > > Key: HBASE-9116 > URL: https://issues.apache.org/jira/browse/HBASE-9116 > Project: HBase > Issue Type: Improvement > Components: Region Assignment >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.96.0 > > Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, > 9116-3.txt, 9116-4.txt, 9116-5.txt > > > Add a tool that one can run offline to view the favored node mappings for > regions, and also fix the mappings if needed. Such a tool exists in the > 0.89-fb branch. Will port it over to trunk/0.95. -- 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-9348) TerminatedWrapper error decoding, skipping skippable types
[
https://issues.apache.org/jira/browse/HBASE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750985#comment-13750985
]
Hadoop QA commented on HBASE-9348:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600078/0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6919//console
This message is automatically generated.
> TerminatedWrapper error decoding, skipping skippable types
> --
>
> Key: HBASE-9348
> URL: https://issues.apache.org/jira/browse/HBASE-9348
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 0.98.0, 0.96.0
>
> Attachments:
> 0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
>
>
> When {{TerminatedWrapper}} wraps a type which {{isSkippable}}, it does not
> consider the terminator when updating the source buffer position after
> skipping or decoding a value. The tests only covered the non-skippable case.
--
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-9336) Two css files raise release audit warning
[
https://issues.apache.org/jira/browse/HBASE-9336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750983#comment-13750983
]
Hadoop QA commented on HBASE-9336:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599984/0001-HBASE-9336-Add-missing-license-headers-to-css-files.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 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.thrift.TestThriftServer
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6918//console
This message is automatically generated.
> Two css files raise release audit warning
> -
>
> Key: HBASE-9336
> URL: https://issues.apache.org/jira/browse/HBASE-9336
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch
>
>
> From
> https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
> :
> {code}
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
> Lines that start with ? in the release audit report indicate files that
> do not have an Apache license header.
> {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] [Updated] (HBASE-9349) [0.92] NPE in HMaster during shutdown
[
https://issues.apache.org/jira/browse/HBASE-9349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-9349:
--
Attachment: 9349.patch
> [0.92] NPE in HMaster during shutdown
> -
>
> Key: HBASE-9349
> URL: https://issues.apache.org/jira/browse/HBASE-9349
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Attachments: 9349.patch
>
>
> Found this in a run of TestWALObserver:
> {noformat}
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.master.HMaster.shutdown(HMaster.java:1510)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.shutdown(JVMClusterUtil.java:226)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.shutdown(LocalHBaseCluster.java:424)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.shutdown(MiniHBaseCluster.java:417)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniHBaseCluster(HBaseTestingUtility.java:607)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniCluster(HBaseTestingUtility.java:583)
> at
> org.apache.hadoop.hbase.coprocessor.TestWALObserver.teardownAfterClass(TestWALObserver.java:111)
> {noformat}
> if the active master in the minicluster is terminated before fully
> initialized. Needs null checks in HMaster#shutdown.
--
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] [Resolved] (HBASE-9349) [0.92] NPE in HMaster during shutdown
[
https://issues.apache.org/jira/browse/HBASE-9349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-9349.
---
Resolution: Fixed
Fix Version/s: 0.92.3
> [0.92] NPE in HMaster during shutdown
> -
>
> Key: HBASE-9349
> URL: https://issues.apache.org/jira/browse/HBASE-9349
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 0.92.3
>
> Attachments: 9349.patch
>
>
> Found this in a run of TestWALObserver:
> {noformat}
> java.lang.NullPointerException
> at org.apache.hadoop.hbase.master.HMaster.shutdown(HMaster.java:1510)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.shutdown(JVMClusterUtil.java:226)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.shutdown(LocalHBaseCluster.java:424)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.shutdown(MiniHBaseCluster.java:417)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniHBaseCluster(HBaseTestingUtility.java:607)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniCluster(HBaseTestingUtility.java:583)
> at
> org.apache.hadoop.hbase.coprocessor.TestWALObserver.teardownAfterClass(TestWALObserver.java:111)
> {noformat}
> if the active master in the minicluster is terminated before fully
> initialized. Needs null checks in HMaster#shutdown.
--
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-9349) [0.92] NPE in HMaster during shutdown
Andrew Purtell created HBASE-9349:
-
Summary: [0.92] NPE in HMaster during shutdown
Key: HBASE-9349
URL: https://issues.apache.org/jira/browse/HBASE-9349
Project: HBase
Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
Found this in a run of TestWALObserver:
{noformat}
java.lang.NullPointerException
at org.apache.hadoop.hbase.master.HMaster.shutdown(HMaster.java:1510)
at
org.apache.hadoop.hbase.util.JVMClusterUtil.shutdown(JVMClusterUtil.java:226)
at
org.apache.hadoop.hbase.LocalHBaseCluster.shutdown(LocalHBaseCluster.java:424)
at
org.apache.hadoop.hbase.MiniHBaseCluster.shutdown(MiniHBaseCluster.java:417)
at
org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniHBaseCluster(HBaseTestingUtility.java:607)
at
org.apache.hadoop.hbase.HBaseTestingUtility.shutdownMiniCluster(HBaseTestingUtility.java:583)
at
org.apache.hadoop.hbase.coprocessor.TestWALObserver.teardownAfterClass(TestWALObserver.java:111)
{noformat}
if the active master in the minicluster is terminated before fully initialized.
Needs null checks in HMaster#shutdown.
--
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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750966#comment-13750966
]
chunhui shen commented on HBASE-8112:
-
Patch looks good to me
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750954#comment-13750954 ] Hudson commented on HBASE-9342: --- SUCCESS: Integrated in HBase-TRUNK #4437 (See [https://builds.apache.org/job/HBase-TRUNK/4437/]) HBASE-9342 WebUI fixes after bootstrap 3.0 update (eclark: rev 1517731) * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/snapshot.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/table.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/tablesDetailed.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/zk.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/rest/rest.jsp * /hbase/trunk/pom.xml > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9342-0.patch > > -- 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-3696) No durability when running with LocalFileSystem
[
https://issues.apache.org/jira/browse/HBASE-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750952#comment-13750952
]
Hadoop QA commented on HBASE-3696:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600032/HBASE-3696.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6917//console
This message is automatically generated.
> No durability when running with LocalFileSystem
> ---
>
> Key: HBASE-3696
> URL: https://issues.apache.org/jira/browse/HBASE-3696
> Project: HBase
> Issue Type: Bug
> Components: documentation, wal
>Reporter: Todd Lipcon
>Assignee: Harsh J
> Attachments: HBASE-3696.patch
>
>
> LocalFileSystem in Hadoop doesn't currently implement sync(), so when we're
> running in that case, we don't have any durability. This isn't a huge deal
> since it isn't a realistic deployment scenario, but it's probably worth
> documenting. It caused some confusion for a user when a table disappeared
> after killing a standalone instance that was hosting its data in the local FS.
--
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-9348) TerminatedWrapper error decoding, skipping skippable types
[
https://issues.apache.org/jira/browse/HBASE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750951#comment-13750951
]
Hadoop QA commented on HBASE-9348:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600078/0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6916//console
This message is automatically generated.
> TerminatedWrapper error decoding, skipping skippable types
> --
>
> Key: HBASE-9348
> URL: https://issues.apache.org/jira/browse/HBASE-9348
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 0.98.0, 0.96.0
>
> Attachments:
> 0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
>
>
> When {{TerminatedWrapper}} wraps a type which {{isSkippable}}, it does not
> consider the terminator when updating the source buffer position after
> skipping or decoding a value. The tests only covered the non-skippable case.
--
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-8496) Implement tags and the internals of how a tag should look like
[ https://issues.apache.org/jira/browse/HBASE-8496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750944#comment-13750944 ] ramkrishna.s.vasudevan commented on HBASE-8496: --- An update on this Since this feature has moved to 0.98 -> We have added the HFileContext changes -> Done with compression of tags on WAL and HFiles using dictionary (yet to test) -> Making tags optional too. Will update patch on RB after some more testing. > Implement tags and the internals of how a tag should look like > -- > > Key: HBASE-8496 > URL: https://issues.apache.org/jira/browse/HBASE-8496 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.98.0, 0.95.2 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Attachments: Comparison.pdf, HBASE-8496_2.patch, HBASE-8496.patch, > Tag design.pdf, Tag design_updated.pdf, Tag_In_KV_Buffer_For_reference.patch > > > The intent of this JIRA comes from HBASE-7897. > This would help us to decide on the structure and format of how the tags > should look like. -- 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-9344) RegionServer not shutting down upon KeeperException in open region
[
https://issues.apache.org/jira/browse/HBASE-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750943#comment-13750943
]
ramkrishna.s.vasudevan commented on HBASE-9344:
---
+1
> RegionServer not shutting down upon KeeperException in open region
> --
>
> Key: HBASE-9344
> URL: https://issues.apache.org/jira/browse/HBASE-9344
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
> Attachments: 9344-trunk.txt
>
>
> We ran into a situation where due to a Kerberos configuration problem one of
> our region server could not connect to ZK when opening a region. Instead of
> shutting down it continue to try to reconnect. Eventually the master would
> assign the region to another region server. Each time that region server was
> assigned a region it would sit there for 5 mins with the region offline. It
> would have been better if the region server had shut itself down.
> This is in the logs:
> {quote}
> 2013-08-16 17:31:35,999 WARN org.apache.hadoop.hbase.zookeeper.ZKUtil:
> hconnection-0x2407b842ff2012d-0x2407b842ff2012d-0x2407b842ff2012d Unable to
> set watcher on znode (/hbase/hbaseid)
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode =
> AuthFailed for /hbase/hbaseid
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1041)
> at
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:172)
> at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:450)
> at
> org.apache.hadoop.hbase.zookeeper.ClusterId.readClusterIdZNode(ClusterId.java:61)
> at org.apache.hadoop.hbase.zookeeper.ClusterId.getId(ClusterId.java:50)
> at org.apache.hadoop.hbase.zookeeper.ClusterId.hasId(ClusterId.java:44)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.ensureZookeeperTrackers(HConnectionManager.java:616)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:882)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:857)
> at org.apache.hadoop.hbase.client.HTable.finishSetup(HTable.java:233)
> at org.apache.hadoop.hbase.client.HTable.(HTable.java:173)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getHTable(MetaReader.java:201)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getMetaHTable(MetaReader.java:227)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getCatalogHTable(MetaReader.java:214)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.putToCatalogTable(MetaEditor.java:91)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.updateLocation(MetaEditor.java:296)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.updateRegionLocation(MetaEditor.java:276)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.postOpenDeployTasks(HRegionServer.java:1828)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler$PostOpenDeployTasksThread.run(OpenRegionHandler.java:240)
> {quote}
> I think the RS should shut itself down instead.
--
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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750937#comment-13750937
]
Ted Yu commented on HBASE-8112:
---
{code}
+ * partially executed results. Use {@link #batchCallback(List, Object[],
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback)} instead.
{code}
Can you wrap long line ?
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-9278) Reading Pre-namespace meta table edits kills the reader
[
https://issues.apache.org/jira/browse/HBASE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Vashishtha updated HBASE-9278:
---
Attachment: HBase-9278-v1-1.patch
Pretty sure TestFullLogReconstruction failure is not related. Re-attaching to
let qa run again.
> Reading Pre-namespace meta table edits kills the reader
> ---
>
> Key: HBASE-9278
> URL: https://issues.apache.org/jira/browse/HBASE-9278
> Project: HBase
> Issue Type: Bug
> Components: migration, wal
>Affects Versions: 0.95.2
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBase-9278-v0.patch, HBase-9278-v1-1.patch,
> HBase-9278-v1.patch
>
>
> In upgrading to 0.96, there might be some meta/root table edits. Currently,
> we are just killing SplitLogWorker thread in case it sees any META, or ROOT
> waledit, which blocks log splitting/replaying of remaining WALs.
> {code}
> 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker
> (SplitLogWorker.java:run(210)) - unexpected error
> java.lang.IllegalArgumentException: .META. no longer exists. The table has
> been renamed to hbase:meta
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
> at
> org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:209)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:138)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.grabTask(SplitLogWorker.java:358)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.taskLoop(SplitLogWorker.java:245)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.run(SplitLogWorker.java:205)
> at java.lang.Thread.run(Thread.java:662)
> 2013-08-20 15:45:16,999 INFO regionserver.SplitLogWorker
> (SplitLogWorker.java:run(212)) - SplitLogWorker localhost,60020,1377035111898
> exiting
> {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] [Updated] (HBASE-4848) TestScanner failing because hostname can't be null
[ https://issues.apache.org/jira/browse/HBASE-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HBASE-4848: --- Resolution: Fixed Status: Resolved (was: Patch Available) Marking as resolved per previous comment(s). > TestScanner failing because hostname can't be null > -- > > Key: HBASE-4848 > URL: https://issues.apache.org/jira/browse/HBASE-4848 > Project: HBase > Issue Type: Bug >Affects Versions: 0.90.5 >Reporter: stack >Assignee: stack > Fix For: 0.92.0, 0.90.5 > > Attachments: 4848-092.txt, 4848.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-9110) Meta region edits not recovered while migrating to 0.96.0
[ https://issues.apache.org/jira/browse/HBASE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750926#comment-13750926 ] stack commented on HBASE-9110: -- Good [~himan...@cloudera.com] So what you think receipe is? Flush server w/ .META. before shutting down? How we going to know we need the hbck trick? > Meta region edits not recovered while migrating to 0.96.0 > - > > Key: HBASE-9110 > URL: https://issues.apache.org/jira/browse/HBASE-9110 > Project: HBase > Issue Type: Sub-task > Components: migration >Affects Versions: 0.95.2, 0.94.10 >Reporter: Himanshu Vashishtha >Priority: Critical > Fix For: 0.96.0 > > > I was doing the migration testing from 0.94.11-snapshot to 0.95.0, and faced > this issue. > 1) Do some edits in meta table (for eg, create a table). > 2) Kill the cluster. > (I used kill because we would be doing log splitting when upgrading anyway). > 3) There is some dependency on WALs. Upgrade the bits to 0.95.2-snapshot. > Start the cluster. > Every thing comes up. I see log splitting happening as expected. But, the > WAL-data for meta table is missing. > I could see recovered.edits file for meta created, and placed at the right > location. It is just that the new HMaster code tries to recover meta by > looking at meta prefix in the log name, and if it didn't find one, just opens > the meta region. So, the recovered.edits file, created afterwards, is not > honored. > Opening this jira to let folks give their opinions about how to tackle this > migration 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-5115) Change HBase "color" from purple to "International Orange (Engineering)"
[ https://issues.apache.org/jira/browse/HBASE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750925#comment-13750925 ] stack commented on HBASE-5115: -- [~qwertymaniac] Thanks > Change HBase "color" from purple to "International Orange (Engineering)" > > > Key: HBASE-5115 > URL: https://issues.apache.org/jira/browse/HBASE-5115 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack > Attachments: 01_orange.png, 01_orange.svg, 5115.txt, H_orange.png, > H_orange.svg > > > See http://en.wikipedia.org/wiki/International_orange See the bit about the > color of the golden gate bridge. -- 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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750923#comment-13750923
]
Hadoop QA commented on HBASE-8112:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600079/HBASE-8112-v0-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 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6915//console
This message is automatically generated.
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-9116) Add a view/edit tool for favored node mappings for regions
[
https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750922#comment-13750922
]
Hadoop QA commented on HBASE-9116:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600075/9116-5.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6914//console
This message is automatically generated.
> Add a view/edit tool for favored node mappings for regions
> --
>
> Key: HBASE-9116
> URL: https://issues.apache.org/jira/browse/HBASE-9116
> Project: HBase
> Issue Type: Improvement
> Components: Region Assignment
>Affects Versions: 0.95.0
>Reporter: Devaraj Das
>Assignee: Devaraj Das
> Fix For: 0.96.0
>
> Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt,
> 9116-3.txt, 9116-4.txt, 9116-5.txt
>
>
> Add a tool that one can run offline to view the favored node mappings for
> regions, and also fix the mappings if needed. Such a tool exists in the
> 0.89-fb branch. Will port it over to trunk/0.95.
--
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-9116) Add a view/edit tool for favored node mappings for regions
[
https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750916#comment-13750916
]
Nick Dimiduk commented on HBASE-9116:
-
Is there a reason for SnapshotOfRegionAssignmentFromMeta to separate
construction from initialization? Why not just call initialize() at the end of
the constructor body?
Is it worth RegionPlacementMaintainer extending AbstractHBaseTool?
Is this necessary -- can you instead separate out "case 2" as a second test?
{noformat}
- @Test(timeout = 18)
+ @Test(timeout = 180)
public void testRegionPlacement() throws Exception {
{noformat}
FYI, it looks like this patch has some noise in it:
{noformat}
$ git apply 9116-5.txt
9116-5.txt:31: trailing whitespace.
java.util.List
9116-5.txt:44: trailing whitespace.
java.util.List
9116-5.txt:165: trailing whitespace.
public java.util.List
9116-5.txt:453: trailing whitespace.
updateRegionInfoBuilder_ =
9116-5.txt:468: trailing whitespace.
warning: squelched 15 whitespace errors
warning: 20 lines add whitespace errors.
{noformat}
> Add a view/edit tool for favored node mappings for regions
> --
>
> Key: HBASE-9116
> URL: https://issues.apache.org/jira/browse/HBASE-9116
> Project: HBase
> Issue Type: Improvement
> Components: Region Assignment
>Affects Versions: 0.95.0
>Reporter: Devaraj Das
>Assignee: Devaraj Das
> Fix For: 0.96.0
>
> Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt,
> 9116-3.txt, 9116-4.txt, 9116-5.txt
>
>
> Add a tool that one can run offline to view the favored node mappings for
> regions, and also fix the mappings if needed. Such a tool exists in the
> 0.89-fb branch. Will port it over to trunk/0.95.
--
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-9101) Addendum to pluggable RpcScheduler
[ https://issues.apache.org/jira/browse/HBASE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750912#comment-13750912 ] stack commented on HBASE-9101: -- [~stepinto] Do you have to pass in an HRegionServer? + RpcScheduler create(Configuration conf, HRegionServer server); Could it be an instance of Server? Or RegionServerServices Why have this constant + public static final String REGION_SERVER_RPC_SCHEDULER_FACTORY_CLASS = + "hbase.region.server.rpc.scheduler.factory.class"; up in HConstants and not in HRegionServer or in the scheduler Interface itself? (i.e. keep constants by the clsss that needs them) Else, patch looks good. > Addendum to pluggable RpcScheduler > -- > > Key: HBASE-9101 > URL: https://issues.apache.org/jira/browse/HBASE-9101 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Reporter: Chao Shi >Assignee: Chao Shi > Fix For: 0.98.0 > > Attachments: hbase-9101.patch, hbase-9101-v2.patch > > > This patch fixes the review comments from [~stack] and a small fix: > - Make RpcScheduler fully pluggable. One can write his/her own implementation > and add it to classpath and specify it by config > "hbase.region.server.rpc.scheduler.factory.class". > - Add unit tests and fix that RpcScheduler.stop is not called (discovered by > tests) -- 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-9101) Addendum to pluggable RpcScheduler
[ https://issues.apache.org/jira/browse/HBASE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750911#comment-13750911 ] Ted Yu commented on HBASE-9101: --- lgtm > Addendum to pluggable RpcScheduler > -- > > Key: HBASE-9101 > URL: https://issues.apache.org/jira/browse/HBASE-9101 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Reporter: Chao Shi >Assignee: Chao Shi > Fix For: 0.98.0 > > Attachments: hbase-9101.patch, hbase-9101-v2.patch > > > This patch fixes the review comments from [~stack] and a small fix: > - Make RpcScheduler fully pluggable. One can write his/her own implementation > and add it to classpath and specify it by config > "hbase.region.server.rpc.scheduler.factory.class". > - Add unit tests and fix that RpcScheduler.stop is not called (discovered by > tests) -- 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-9101) Addendum to pluggable RpcScheduler
[ https://issues.apache.org/jira/browse/HBASE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750909#comment-13750909 ] Chao Shi commented on HBASE-9101: - Hi [~te...@apache.org], could you please have a look at this patch? As we're developing our custom RpcScheduler, we will need this to make it work. > Addendum to pluggable RpcScheduler > -- > > Key: HBASE-9101 > URL: https://issues.apache.org/jira/browse/HBASE-9101 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Reporter: Chao Shi >Assignee: Chao Shi > Fix For: 0.98.0 > > Attachments: hbase-9101.patch, hbase-9101-v2.patch > > > This patch fixes the review comments from [~stack] and a small fix: > - Make RpcScheduler fully pluggable. One can write his/her own implementation > and add it to classpath and specify it by config > "hbase.region.server.rpc.scheduler.factory.class". > - Add unit tests and fix that RpcScheduler.stop is not called (discovered by > tests) -- 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-9336) Two css files raise release audit warning
[
https://issues.apache.org/jira/browse/HBASE-9336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9336:
Status: Open (was: Patch Available)
> Two css files raise release audit warning
> -
>
> Key: HBASE-9336
> URL: https://issues.apache.org/jira/browse/HBASE-9336
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch
>
>
> From
> https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
> :
> {code}
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
> Lines that start with ? in the release audit report indicate files that
> do not have an Apache license header.
> {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] [Updated] (HBASE-9336) Two css files raise release audit warning
[
https://issues.apache.org/jira/browse/HBASE-9336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9336:
Status: Patch Available (was: Open)
> Two css files raise release audit warning
> -
>
> Key: HBASE-9336
> URL: https://issues.apache.org/jira/browse/HBASE-9336
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch
>
>
> From
> https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
> :
> {code}
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
> !?
> /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
> Lines that start with ? in the release audit report indicate files that
> do not have an Apache license header.
> {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] [Updated] (HBASE-9283) Struct and StructIterator should properly handle trailing nulls
[ https://issues.apache.org/jira/browse/HBASE-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-9283: Attachment: 0001-HBASE-9283-Struct-trailing-null-handling.patch Updated patch. More rigorous unit tests and updated documentation. Depends on HBASE-9348. > Struct and StructIterator should properly handle trailing nulls > --- > > Key: HBASE-9283 > URL: https://issues.apache.org/jira/browse/HBASE-9283 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 0.98.0, 0.96.0 > > Attachments: 0001-HBASE-9283-Struct-trailing-null-handling.patch, > 0001-HBASE-9283-Struct-trailing-null-handling.patch, > 0001-HBASE-9283-Struct-trailing-null-handling.patch > > > For a composite row key, Phoenix strips off trailing null columns values in > the row key. The reason this is important is that then new nullable row key > columns can be added to a schema without requiring any data upgrade to > existing rows. Otherwise, adding new row key columns to the end of a schema > becomes extremely cumbersome, as you'd need to delete all existing rows and > add them back with a row key that includes a null value. > Rather than Phoenix needing to modify the iteration code everywhere (as > [~ndimiduk] outlined here: > https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499), > it'd be better if StructIterator handled this out-of-the-box. Otherwise, if > Phoenix has to specialize this, we'd lose the interop piece which is the > justification for switching our type system to this new one in the first > place. -- 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-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)
[
https://issues.apache.org/jira/browse/HBASE-9337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750895#comment-13750895
]
Hudson commented on HBASE-9337:
---
SUCCESS: Integrated in HBase-TRUNK #4436 (See
[https://builds.apache.org/job/HBase-TRUNK/4436/])
HBASE-9337 shell 'user_permission' throws no method 'toStringBinary' for
(o.a.h.h.TableName) (mbertozzi: rev 1517665)
* /hbase/trunk/hbase-server/src/main/ruby/hbase/security.rb
> shell 'user_permission' throws no method 'toStringBinary' for
> (o.a.h.h.TableName)
> --
>
> Key: HBASE-9337
> URL: https://issues.apache.org/jira/browse/HBASE-9337
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9337-v0.patch
>
>
> the user_permission shell code is trying to convert a TableName object to a
> string, and it throws
> {code}
> hbase(main):010:0> user_permission
> UserTable,Family,Qualifier:Permission
>
>
> ERROR: no method 'toStringBinary' for arguments
> (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
> available overloads:
> (java.nio.ByteBuffer)
> (byte[])
> {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-9339) Fix saveVersion.sh's GIT awareness.
[ https://issues.apache.org/jira/browse/HBASE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750896#comment-13750896 ] Hudson commented on HBASE-9339: --- SUCCESS: Integrated in HBase-TRUNK #4436 (See [https://builds.apache.org/job/HBase-TRUNK/4436/]) HBASE-9339 Fix saveVersion.sh's GIT awareness. (eclark: rev 1517695) * /hbase/trunk/hbase-common/src/saveVersion.sh > Fix saveVersion.sh's GIT awareness. > --- > > Key: HBASE-9339 > URL: https://issues.apache.org/jira/browse/HBASE-9339 > Project: HBase > Issue Type: Task > Components: build >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9339-0.patch > > > Many developers are using git to work with HBase. We should make the build > scripts git aware (point to a git hash ) for revision. -- 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-9340) revoke 'user' throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750898#comment-13750898
]
Hudson commented on HBASE-9340:
---
SUCCESS: Integrated in HBase-TRUNK #4436 (See
[https://builds.apache.org/job/HBase-TRUNK/4436/])
HBASE-9340 revoke 'user' throws ArrayIndexOutOfBoundsException (mbertozzi: rev
1517684)
* /hbase/trunk/hbase-server/src/main/ruby/hbase/security.rb
> revoke 'user' throws ArrayIndexOutOfBoundsException
> ---
>
> Key: HBASE-9340
> URL: https://issues.apache.org/jira/browse/HBASE-9340
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9340-v0.patch
>
>
> Trying to revoke a global rights throws
> {code}
> hbase(main):004:0> revoke 'test'
> Java::JavaLang::ArrayIndexOutOfBoundsException: 3
> {code}
> The problem is that jruby is not able to do the bind with revoke(...,
> Permission.Action... actions)
--
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-9332) OrderedBytes does not decode Strings correctly
[ https://issues.apache.org/jira/browse/HBASE-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750897#comment-13750897 ] Hudson commented on HBASE-9332: --- SUCCESS: Integrated in HBase-TRUNK #4436 (See [https://builds.apache.org/job/HBase-TRUNK/4436/]) HBASE-9332 OrderedBytes does not decode Strings correctly (stack: rev 1517655) * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/SimplePositionedByteRange.java * /hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestOrderedBytes.java > OrderedBytes does not decode Strings correctly > -- > > Key: HBASE-9332 > URL: https://issues.apache.org/jira/browse/HBASE-9332 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 0.98.0, 0.96.0 > > Attachments: > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch > > > While writing a test describing the expected behavior for HBASE-9283, I > discovered an error in String decoding. The error occurs when the string > being decoded does not start at position 0. The unit tests were originally > designed to cover this scenario, but this condition slipped in the transition > to PositionedByteBuffer. > Update the tests to cover this scenario and fix the String decoding logic. > String appears to be the only codec affected. This error is only in decoding > -- encoding produces correct 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] [Updated] (HBASE-3696) No durability when running with LocalFileSystem
[ https://issues.apache.org/jira/browse/HBASE-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HBASE-3696: --- Assignee: Harsh J Status: Patch Available (was: Open) > No durability when running with LocalFileSystem > --- > > Key: HBASE-3696 > URL: https://issues.apache.org/jira/browse/HBASE-3696 > Project: HBase > Issue Type: Bug > Components: documentation, wal >Reporter: Todd Lipcon >Assignee: Harsh J > Attachments: HBASE-3696.patch > > > LocalFileSystem in Hadoop doesn't currently implement sync(), so when we're > running in that case, we don't have any durability. This isn't a huge deal > since it isn't a realistic deployment scenario, but it's probably worth > documenting. It caused some confusion for a user when a table disappeared > after killing a standalone instance that was hosting its data in the local FS. -- 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] [Resolved] (HBASE-5115) Change HBase "color" from purple to "International Orange (Engineering)"
[ https://issues.apache.org/jira/browse/HBASE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J resolved HBASE-5115. Resolution: Fixed > Change HBase "color" from purple to "International Orange (Engineering)" > > > Key: HBASE-5115 > URL: https://issues.apache.org/jira/browse/HBASE-5115 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack > Attachments: 01_orange.png, 01_orange.svg, 5115.txt, H_orange.png, > H_orange.svg > > > See http://en.wikipedia.org/wiki/International_orange See the bit about the > color of the golden gate bridge. -- 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-5105) TestImportTsv failed with hadoop 0.22
[ https://issues.apache.org/jira/browse/HBASE-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J updated HBASE-5105: --- Resolution: Fixed Fix Version/s: 0.92.2 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > TestImportTsv failed with hadoop 0.22 > - > > Key: HBASE-5105 > URL: https://issues.apache.org/jira/browse/HBASE-5105 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.92.0 >Reporter: Ming Ma >Assignee: Ming Ma > Fix For: 0.92.2 > > Attachments: HBASE-5105-0.92.patch > > > java.io.FileNotFoundException: File does not exist: > /home/henkins/.m2/repository/org/apache/hadoop/hadoop-mapred/0.22-SNAPSHOT/hadoop-mapred-0.22-SNAPSHOT.jar > at > org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:742) > at > org.apache.hadoop.mapreduce.filecache.TrackerDistributedCacheManager.getFileStatus(TrackerDistributedCacheManager.java:331) > at > org.apache.hadoop.mapreduce.filecache.TrackerDistributedCacheManager.determineTimestamps(TrackerDistributedCacheManager.java:711) > at > org.apache.hadoop.mapreduce.JobSubmitter.copyAndConfigureFiles(JobSubmitter.java:245) > at > org.apache.hadoop.mapreduce.JobSubmitter.copyAndConfigureFiles(JobSubmitter.java:283) > at > org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:350) > at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1045) > at org.apache.hadoop.mapreduce.Job$2.run(Job.java:1042) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:396) > at > org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1153) > at org.apache.hadoop.mapreduce.Job.submit(Job.java:1042) > at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1062) > at > org.apache.hadoop.hbase.mapreduce.TestImportTsv.doMROnTableTest(TestImportTsv.java:215) > at > org.apache.hadoop.hbase.mapreduce.TestImportTsv.testMROnTable(TestImportTsv.java:165) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) -- 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-5115) Change HBase "color" from purple to "International Orange (Engineering)"
[ https://issues.apache.org/jira/browse/HBASE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750892#comment-13750892 ] Harsh J commented on HBASE-5115: Should we mark this as closed as it was already committed over a year ago? > Change HBase "color" from purple to "International Orange (Engineering)" > > > Key: HBASE-5115 > URL: https://issues.apache.org/jira/browse/HBASE-5115 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack > Attachments: 01_orange.png, 01_orange.svg, 5115.txt, H_orange.png, > H_orange.svg > > > See http://en.wikipedia.org/wiki/International_orange See the bit about the > color of the golden gate bridge. -- 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-9339) Fix saveVersion.sh's GIT awareness.
[ https://issues.apache.org/jira/browse/HBASE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750884#comment-13750884 ] Hudson commented on HBASE-9339: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/]) HBASE-9339 Fix saveVersion.sh's GIT awareness. (eclark: rev 1517695) * /hbase/trunk/hbase-common/src/saveVersion.sh > Fix saveVersion.sh's GIT awareness. > --- > > Key: HBASE-9339 > URL: https://issues.apache.org/jira/browse/HBASE-9339 > Project: HBase > Issue Type: Task > Components: build >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9339-0.patch > > > Many developers are using git to work with HBase. We should make the build > scripts git aware (point to a git hash ) for revision. -- 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-9340) revoke 'user' throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750887#comment-13750887
]
Hudson commented on HBASE-9340:
---
FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/])
HBASE-9340 revoke 'user' throws ArrayIndexOutOfBoundsException (mbertozzi: rev
1517684)
* /hbase/trunk/hbase-server/src/main/ruby/hbase/security.rb
> revoke 'user' throws ArrayIndexOutOfBoundsException
> ---
>
> Key: HBASE-9340
> URL: https://issues.apache.org/jira/browse/HBASE-9340
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9340-v0.patch
>
>
> Trying to revoke a global rights throws
> {code}
> hbase(main):004:0> revoke 'test'
> Java::JavaLang::ArrayIndexOutOfBoundsException: 3
> {code}
> The problem is that jruby is not able to do the bind with revoke(...,
> Permission.Action... actions)
--
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-9312) Lower StochasticLoadBalancer's default max run time
[ https://issues.apache.org/jira/browse/HBASE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750882#comment-13750882 ] Hudson commented on HBASE-9312: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/]) HBASE-9312 Lower StochasticLoadBalancer's default max run time (eclark: rev 1517647) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java > Lower StochasticLoadBalancer's default max run time > > > Key: HBASE-9312 > URL: https://issues.apache.org/jira/browse/HBASE-9312 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Jean-Daniel Cryans >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9312-0.patch > > > Three things about the 1 minute it takes to decide if we want to balance or > not: > - 1 minute is also the default socket timeout, so if you call "balancer" in > the shell you often get a SocketTimeoutException back. Bad user experience. > - Elliott was telling me that we might not even need 1 minute to compute a > good balance anyways because of other improvements. I tested 30 seconds on a > badly balanced cluster and it worked well. > - I personally think that 1 minute is too much time (Elliott disagrees). -- 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-9329) SnapshotManager should check for directory existance before throwing a warning.
[
https://issues.apache.org/jira/browse/HBASE-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750883#comment-13750883
]
Hudson commented on HBASE-9329:
---
FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/])
HBASE-9329 SnapshotManager should check for directory existance before throwing
a warning (Jean-Marc Spaggiari) (mbertozzi: rev 1517608)
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java
> SnapshotManager should check for directory existance before throwing a
> warning.
> ---
>
> Key: HBASE-9329
> URL: https://issues.apache.org/jira/browse/HBASE-9329
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>Priority: Trivial
> Fix For: 0.98.0, 0.95.2, 0.94.12
>
> Attachments: HBASE-9329-v0-trunk.patch
>
>
> {quote}
> 2013-08-23 17:57:24,277 WARN
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete
> working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
> {quote}
> I don't have any .hbase-snapshot directory, so there is no need to try to
> delete the .tmp directory into it. Might first need to check if this
> directory exist.
--
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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750885#comment-13750885 ] Hudson commented on HBASE-9342: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/]) HBASE-9342 WebUI fixes after bootstrap 3.0 update (eclark: rev 1517731) * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/snapshot.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/table.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/tablesDetailed.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/master/zk.jsp * /hbase/trunk/hbase-server/src/main/resources/hbase-webapps/rest/rest.jsp * /hbase/trunk/pom.xml > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9342-0.patch > > -- 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-9332) OrderedBytes does not decode Strings correctly
[ https://issues.apache.org/jira/browse/HBASE-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750886#comment-13750886 ] Hudson commented on HBASE-9332: --- FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/]) HBASE-9332 OrderedBytes does not decode Strings correctly (stack: rev 1517655) * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/SimplePositionedByteRange.java * /hbase/trunk/hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestOrderedBytes.java > OrderedBytes does not decode Strings correctly > -- > > Key: HBASE-9332 > URL: https://issues.apache.org/jira/browse/HBASE-9332 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 0.98.0, 0.96.0 > > Attachments: > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, > 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch > > > While writing a test describing the expected behavior for HBASE-9283, I > discovered an error in String decoding. The error occurs when the string > being decoded does not start at position 0. The unit tests were originally > designed to cover this scenario, but this condition slipped in the transition > to PositionedByteBuffer. > Update the tests to cover this scenario and fix the String decoding logic. > String appears to be the only codec affected. This error is only in decoding > -- encoding produces correct 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-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)
[
https://issues.apache.org/jira/browse/HBASE-9337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750881#comment-13750881
]
Hudson commented on HBASE-9337:
---
FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #698 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/698/])
HBASE-9337 shell 'user_permission' throws no method 'toStringBinary' for
(o.a.h.h.TableName) (mbertozzi: rev 1517665)
* /hbase/trunk/hbase-server/src/main/ruby/hbase/security.rb
> shell 'user_permission' throws no method 'toStringBinary' for
> (o.a.h.h.TableName)
> --
>
> Key: HBASE-9337
> URL: https://issues.apache.org/jira/browse/HBASE-9337
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9337-v0.patch
>
>
> the user_permission shell code is trying to convert a TableName object to a
> string, and it throws
> {code}
> hbase(main):010:0> user_permission
> UserTable,Family,Qualifier:Permission
>
>
> ERROR: no method 'toStringBinary' for arguments
> (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
> available overloads:
> (java.nio.ByteBuffer)
> (byte[])
> {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-9339) Fix saveVersion.sh's GIT awareness.
[ https://issues.apache.org/jira/browse/HBASE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750871#comment-13750871 ] Hudson commented on HBASE-9339: --- SUCCESS: Integrated in hbase-0.95-on-hadoop2 #274 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/274/]) HBASE-9339 Fix saveVersion.sh's GIT awareness. (eclark: rev 1517694) * /hbase/branches/0.95/hbase-common/src/saveVersion.sh > Fix saveVersion.sh's GIT awareness. > --- > > Key: HBASE-9339 > URL: https://issues.apache.org/jira/browse/HBASE-9339 > Project: HBase > Issue Type: Task > Components: build >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9339-0.patch > > > Many developers are using git to work with HBase. We should make the build > scripts git aware (point to a git hash ) for revision. -- 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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750872#comment-13750872 ] Hudson commented on HBASE-9342: --- SUCCESS: Integrated in hbase-0.95-on-hadoop2 #274 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/274/]) HBASE-9342 WebUI fixes after bootstrap 3.0 update (eclark: rev 1517732) * /hbase/branches/0.95/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon * /hbase/branches/0.95/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/snapshot.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/table.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/tablesDetailed.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/zk.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/rest/rest.jsp * /hbase/branches/0.95/pom.xml > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9342-0.patch > > -- 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-9340) revoke 'user' throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750873#comment-13750873
]
Hudson commented on HBASE-9340:
---
SUCCESS: Integrated in hbase-0.95-on-hadoop2 #274 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/274/])
HBASE-9340 revoke 'user' throws ArrayIndexOutOfBoundsException (mbertozzi: rev
1517683)
* /hbase/branches/0.95/hbase-server/src/main/ruby/hbase/security.rb
> revoke 'user' throws ArrayIndexOutOfBoundsException
> ---
>
> Key: HBASE-9340
> URL: https://issues.apache.org/jira/browse/HBASE-9340
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9340-v0.patch
>
>
> Trying to revoke a global rights throws
> {code}
> hbase(main):004:0> revoke 'test'
> Java::JavaLang::ArrayIndexOutOfBoundsException: 3
> {code}
> The problem is that jruby is not able to do the bind with revoke(...,
> Permission.Action... actions)
--
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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-8112:
---
Status: Patch Available (was: Open)
What's about attached version? I also figured that batchCallback had the same
"issue"...
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-8112:
---
Attachment: HBASE-8112-v0-trunk.patch
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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] [Assigned] (HBASE-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari reassigned HBASE-8112:
--
Assignee: Jean-Marc Spaggiari
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Attachments: HBASE-8112-v0-trunk.patch
>
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750867#comment-13750867 ] Hudson commented on HBASE-9342: --- SUCCESS: Integrated in hbase-0.95 #495 (See [https://builds.apache.org/job/hbase-0.95/495/]) HBASE-9342 WebUI fixes after bootstrap 3.0 update (eclark: rev 1517732) * /hbase/branches/0.95/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon * /hbase/branches/0.95/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RSStatusTmpl.jamon * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/snapshot.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/table.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/tablesDetailed.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/master/zk.jsp * /hbase/branches/0.95/hbase-server/src/main/resources/hbase-webapps/rest/rest.jsp * /hbase/branches/0.95/pom.xml > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9342-0.patch > > -- 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-9340) revoke 'user' throws ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750868#comment-13750868
]
Hudson commented on HBASE-9340:
---
SUCCESS: Integrated in hbase-0.95 #495 (See
[https://builds.apache.org/job/hbase-0.95/495/])
HBASE-9340 revoke 'user' throws ArrayIndexOutOfBoundsException (mbertozzi: rev
1517683)
* /hbase/branches/0.95/hbase-server/src/main/ruby/hbase/security.rb
> revoke 'user' throws ArrayIndexOutOfBoundsException
> ---
>
> Key: HBASE-9340
> URL: https://issues.apache.org/jira/browse/HBASE-9340
> Project: HBase
> Issue Type: Bug
> Components: security, shell
>Affects Versions: 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9340-v0.patch
>
>
> Trying to revoke a global rights throws
> {code}
> hbase(main):004:0> revoke 'test'
> Java::JavaLang::ArrayIndexOutOfBoundsException: 3
> {code}
> The problem is that jruby is not able to do the bind with revoke(...,
> Permission.Action... actions)
--
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-9339) Fix saveVersion.sh's GIT awareness.
[ https://issues.apache.org/jira/browse/HBASE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750866#comment-13750866 ] Hudson commented on HBASE-9339: --- SUCCESS: Integrated in hbase-0.95 #495 (See [https://builds.apache.org/job/hbase-0.95/495/]) HBASE-9339 Fix saveVersion.sh's GIT awareness. (eclark: rev 1517694) * /hbase/branches/0.95/hbase-common/src/saveVersion.sh > Fix saveVersion.sh's GIT awareness. > --- > > Key: HBASE-9339 > URL: https://issues.apache.org/jira/browse/HBASE-9339 > Project: HBase > Issue Type: Task > Components: build >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9339-0.patch > > > Many developers are using git to work with HBase. We should make the build > scripts git aware (point to a git hash ) for revision. -- 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-8549) Integrate Favored Nodes into StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750865#comment-13750865 ] Devaraj Das commented on HBASE-8549: [~stack] agree with you generally. There are some (small) number of use cases that might benefit from purely locality but yeah agree that one balancer is better. In this patch, the issue is that the FavoredNodes stuff is enabled only when the balancer configured is FavoredNodeLoadBalancer. We probably can remove that flag or have that flag be controlled by another configuration... > Integrate Favored Nodes into StochasticLoadBalancer > --- > > Key: HBASE-8549 > URL: https://issues.apache.org/jira/browse/HBASE-8549 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 0.98.0, 0.95.1 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-8549-0.patch > > > Right now we have a FavoredNodeLoadBalancer. It would be pretty easy to > integrate the favored node list into the strochastic balancer. Then we would > have the best of both worlds. -- 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-9348) TerminatedWrapper error decoding, skipping skippable types
[
https://issues.apache.org/jira/browse/HBASE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9348:
Attachment: 0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
> TerminatedWrapper error decoding, skipping skippable types
> --
>
> Key: HBASE-9348
> URL: https://issues.apache.org/jira/browse/HBASE-9348
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 0.98.0, 0.96.0
>
> Attachments:
> 0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
>
>
> When {{TerminatedWrapper}} wraps a type which {{isSkippable}}, it does not
> consider the terminator when updating the source buffer position after
> skipping or decoding a value. The tests only covered the non-skippable case.
--
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-9348) TerminatedWrapper error decoding, skipping skippable types
[
https://issues.apache.org/jira/browse/HBASE-9348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9348:
Status: Patch Available (was: Open)
> TerminatedWrapper error decoding, skipping skippable types
> --
>
> Key: HBASE-9348
> URL: https://issues.apache.org/jira/browse/HBASE-9348
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 0.98.0, 0.96.0
>
> Attachments:
> 0001-HBASE-9348-TerminatedWrapper-skippable-types-bug.patch
>
>
> When {{TerminatedWrapper}} wraps a type which {{isSkippable}}, it does not
> consider the terminator when updating the source buffer position after
> skipping or decoding a value. The tests only covered the non-skippable case.
--
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-9348) TerminatedWrapper error decoding, skipping skippable types
Nick Dimiduk created HBASE-9348:
---
Summary: TerminatedWrapper error decoding, skipping skippable types
Key: HBASE-9348
URL: https://issues.apache.org/jira/browse/HBASE-9348
Project: HBase
Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
Fix For: 0.98.0, 0.96.0
When {{TerminatedWrapper}} wraps a type which {{isSkippable}}, it does not
consider the terminator when updating the source buffer position after skipping
or decoding a value. The tests only covered the non-skippable case.
--
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-9347) Support for adding filters for client requests
[
https://issues.apache.org/jira/browse/HBASE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750864#comment-13750864
]
Hadoop QA commented on HBASE-9347:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600069/HBASE-9347_94.00.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6912//console
This message is automatically generated.
> Support for adding filters for client requests
> --
>
> Key: HBASE-9347
> URL: https://issues.apache.org/jira/browse/HBASE-9347
> Project: HBase
> Issue Type: Improvement
> Components: REST
>Affects Versions: 0.94.11
>Reporter: Vandana Ayyalasomayajula
>Assignee: Vandana Ayyalasomayajula
> Attachments: HBASE-9347_94.00.patch
>
>
> Currently there is no support for specifying filters for filtering client
> requests. It will be useful if filters can be configured through hbase
> configuration.
--
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-9343) Implement stateless scanner for Stargate
[
https://issues.apache.org/jira/browse/HBASE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750862#comment-13750862
]
Hadoop QA commented on HBASE-9343:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600031/HBASE-9343_94.00.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 13 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6911//console
This message is automatically generated.
> Implement stateless scanner for Stargate
>
>
> Key: HBASE-9343
> URL: https://issues.apache.org/jira/browse/HBASE-9343
> Project: HBase
> Issue Type: Improvement
> Components: REST
>Affects Versions: 0.94.11
>Reporter: Vandana Ayyalasomayajula
>Assignee: Vandana Ayyalasomayajula
>Priority: Minor
> Attachments: HBASE-9343_94.00.patch
>
>
> The current scanner implementation for scanner stores state and hence not
> very suitable for REST server failure scenarios. The current JIRA proposes to
> implement a stateless scanner. In the first version of the patch, a new
> resource class "ScanResource" has been added and all the scan parameters will
> be specified as query params.
> The following are the scan parameters
> startrow - The start row for the scan.
> endrow - The end row for the scan.
> columns - The columns to scan.
> starttime, endtime - To only retrieve columns within a specific range of
> version timestamps,both start and end time must be specified.
> maxversions - To limit the number of versions of each column to be returned.
> batchsize - To limit the maximum number of values returned for each call to
> next().
> limit - The number of rows to return in the scan operation.
> More on start row, end row and limit parameters.
> 1. If start row, end row and limit not specified, then the whole table will
> be scanned.
> 2. If start row and limit (say N) is specified, then the scan operation will
> return N rows from the start row specified.
> 3. If only limit parameter is specified, then the scan operation will return
> N rows from the start of the table.
> 4. If limit and end row are specified, then the scan operation will return N
> rows from start of table till the end row. If the end row is
> reached before N rows ( say M and M < N ), then M rows will be returned to
> the user.
> 5. If start row, end row and limit (say N ) are specified and N < number
> of rows between start row and end row, then N rows from start row
> will be returned to the user. If N > (number of rows between start row and
> end row (say M), then M number of rows will be returned to the
> user.
--
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-8410) Basic quota support for namespaces
[
https://issues.apache.org/jira/browse/HBASE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750858#comment-13750858
]
Hadoop QA commented on HBASE-8410:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599768/HBASE-8410_trunk_3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 8 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6910//console
This message is automatically generated.
> Basic quota support for namespaces
> --
>
> Key: HBASE-8410
> URL: https://issues.apache.org/jira/browse/HBASE-8410
> Project: HBase
> Issue Type: Sub-task
>Reporter: Francis Liu
>Assignee: Vandana Ayyalasomayajula
> Attachments: HBASE_8410_1_trunk.patch, HBASE_8410.patch,
> HBASE-8410_trunk_2.patch, HBASE-8410_trunk_3.patch
>
>
> This task involves creating an observer which provides basic quota support to
> namespaces in terms of (1) number of tables and (2) number of regions. The
> quota support can be enabled by setting:
>
> hbase.coprocessor.region.classes
> org.apache.hadoop.hbase.namespace.NamespaceController
>
>
> hbase.coprocessor.master.classes
> org.apache.hadoop.hbase.namespace.NamespaceController
>
> in the hbase-site.xml.
> To add quotas to namespace, while creating namespace properties need to be
> added.
> Examples:
> 1. namespace_create 'ns1', {'hbase.namespace.quota.maxregion'=>'10'}
> 2. 1. namespace_create 'ns2', {'hbase.namespace.quota.maxtables'=>'2'},
> {'hbase.namespace.quota.maxregion'=>'5'}
> The quotas can be modified/added to namespace at any point of time.
--
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-9208) ReplicationLogCleaner slow at large scale
[
https://issues.apache.org/jira/browse/HBASE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750853#comment-13750853
]
Hadoop QA commented on HBASE-9208:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600055/HBASE-9208-v3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6908//console
This message is automatically generated.
> ReplicationLogCleaner slow at large scale
> -
>
> Key: HBASE-9208
> URL: https://issues.apache.org/jira/browse/HBASE-9208
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: Dave Latham
>Assignee: Dave Latham
> Fix For: 0.94.12, 0.96.0
>
> Attachments: HBASE-9208-0.94.patch, HBASE-9208-0.94-v2.patch,
> HBASE-9208.patch, HBASE-9208-v2.patch, HBASE-9208-v3.patch
>
>
> At a large scale the ReplicationLogCleaner fails to clean up .oldlogs as fast
> as the cluster is producing them. For each old HLog file that has been
> replicated and should be deleted the ReplicationLogCleaner checks every
> replication queue in ZooKeeper before removing it. This means that as a
> cluster scales up the number of files to delete scales as well as the time to
> delete each file so the cleanup chore scales quadratically. In our case it
> reached the point where the oldlogs were growing faster than they were being
> cleaned up.
> We're now running with a patch that allows the ReplicationLogCleaner to
> refresh its list of files in the replication queues from ZooKeeper just once
> for each batch of files the CleanerChore wants to evaluate.
> I'd propose updating FileCleanerDelegate to take a List rather
> than a single one at a time. This would allow file cleaners that check an
> external resource for references such as ZooKeeper (for
> ReplicationLogCleaner) or HDFS (for SnapshotLogCleaner which looks like it
> may also have similar trouble at scale) to load those references once per
> batch rather than for every log.
--
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-9116) Add a view/edit tool for favored node mappings for regions
[ https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-9116: --- Attachment: 9116-5.txt Sorry for the delay in responding. I couldn't get to it until now. Attached patch takes care of the comments. bq. Why updateFavoredNodes takes an OpenRegionRequest? That's because the argument serves all the purpose of what is needed in the updateFavoredNodes RPC. I am open to defining a new argument if you think that'd be better. bq. Is the hbase-site.xml change intentional? Nope. Accidental.. bq. Can we create a similar putsToMetaTable method which takes a conf in MetaEditor? We need to handle exceptions and close the table at the end. Done (added close) bq. Perhaps, it is better to log the stack trace as well Done. bq. Some function may not throw exception declared Fixed. bq. Good stuff. Is this still WIP? How can we use this? Edit the meta table from hbase shell? This is mostly complete. It needs more real life testing. The RegionPlacementMaintainer in the patch has the commands to update meta (can be run like a regular Java app). That's the tool added (which is the majority of the code in this patch). > Add a view/edit tool for favored node mappings for regions > -- > > Key: HBASE-9116 > URL: https://issues.apache.org/jira/browse/HBASE-9116 > Project: HBase > Issue Type: Improvement > Components: Region Assignment >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.96.0 > > Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, > 9116-3.txt, 9116-4.txt, 9116-5.txt > > > Add a tool that one can run offline to view the favored node mappings for > regions, and also fix the mappings if needed. Such a tool exists in the > 0.89-fb branch. Will port it over to trunk/0.95. -- 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-8112) Deprecate HTable#batch(final List)
[
https://issues.apache.org/jira/browse/HBASE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750843#comment-13750843
]
Jean-Marc Spaggiari commented on HBASE-8112:
That's an old one ;) Let me read it again. I will try to upload one.
> Deprecate HTable#batch(final List)
> -
>
> Key: HBASE-8112
> URL: https://issues.apache.org/jira/browse/HBASE-8112
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Priority: Minor
>
> This was brought up by Amit's inquiry on mailing list, entitled 'Batch
> returned value and exception handling'
> Here is his sample code:
> {code}
> Object[] res = null;
> try {
> res = table.batch(batch);
> } catch (RetriesExhaustedWithDetailsException
> retriesExhaustedWithDetailsException) {
> retriesExhaustedWithDetailsException.printStackTrace();
> }
> if (res == null) {
> System.out.println("No results - returned null.");
> }
> {code}
> When RetriesExhaustedWithDetailsException was thrown from batch() call,
> variable res carried value of null.
> Meaning user wouldn't get partial result along with the exception.
> We should deprecate {code}HTable#batch(final List){code} and
> refer to the following method:
> void batch(final List actions, final Object[] results) throws
> IOException, InterruptedException;
--
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-9278) Reading Pre-namespace meta table edits kills the reader
[
https://issues.apache.org/jira/browse/HBASE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750838#comment-13750838
]
Hadoop QA commented on HBASE-9278:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600042/HBase-9278-v1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestFullLogReconstruction
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6907//console
This message is automatically generated.
> Reading Pre-namespace meta table edits kills the reader
> ---
>
> Key: HBASE-9278
> URL: https://issues.apache.org/jira/browse/HBASE-9278
> Project: HBase
> Issue Type: Bug
> Components: migration, wal
>Affects Versions: 0.95.2
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBase-9278-v0.patch, HBase-9278-v1.patch
>
>
> In upgrading to 0.96, there might be some meta/root table edits. Currently,
> we are just killing SplitLogWorker thread in case it sees any META, or ROOT
> waledit, which blocks log splitting/replaying of remaining WALs.
> {code}
> 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker
> (SplitLogWorker.java:run(210)) - unexpected error
> java.lang.IllegalArgumentException: .META. no longer exists. The table has
> been renamed to hbase:meta
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
> at
> org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
> at
> org.ap
[jira] [Updated] (HBASE-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
[ https://issues.apache.org/jira/browse/HBASE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Spaggiari updated HBASE-9346: --- Status: Patch Available (was: Open) Trunk version attached. Tried the 0.94 version only. But there are mostly the same. > HBCK should provide an option to check if regions boundaries are the same in > META and in stores. > > > Key: HBASE-9346 > URL: https://issues.apache.org/jira/browse/HBASE-9346 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 0.94.11, 0.95.2 >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Attachments: HBASE-9346-v0-0.94.patch, HBASE-9346-v1-trunk.patch > > > If META don't have the same region boundaries as the stores files, writes and > read might go to the wrong place. We need to provide a way to check that > withing HBCK. -- 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-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
[ https://issues.apache.org/jira/browse/HBASE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Spaggiari updated HBASE-9346: --- Attachment: HBASE-9346-v1-trunk.patch > HBCK should provide an option to check if regions boundaries are the same in > META and in stores. > > > Key: HBASE-9346 > URL: https://issues.apache.org/jira/browse/HBASE-9346 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 0.95.2, 0.94.11 >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Attachments: HBASE-9346-v0-0.94.patch, HBASE-9346-v1-trunk.patch > > > If META don't have the same region boundaries as the stores files, writes and > read might go to the wrong place. We need to provide a way to check that > withing HBCK. -- 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-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
[
https://issues.apache.org/jira/browse/HBASE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750828#comment-13750828
]
Jean-Marc Spaggiari commented on HBASE-9346:
OK. Seems to be working fine in 0.94. Did some cleanup. I will merge that to
Trunk and upload a patch.
{code}
hbase@node3:~/hbase-0.94.3$ bin/hbase hbck -boundaries
Version: 0.94.12-SNAPSHOT
Number of Tables: 12
Number of live region servers: 8
Number of dead region servers: 0
Master: node3,6,1377564568492
Number of backup masters: 0
.Number of empty REGIONINFO_QUALIFIER rows in .META.: 0
13/08/26 20:51:09 WARN snappy.LoadSnappy: Snappy native library is available
ERROR: Found issues with regions boundaries
13/08/26 20:51:12 WARN util.HBaseFsck: Region's boundaries not alligned between
stores and META for:
13/08/26 20:51:12 WARN util.HBaseFsck:
regionName=work_proposed,\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16,1376139517597.b39bf00b980b632901859761caafb9d0.
metaFirstKey=\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16
metaLastKey=\xF5\x9B@}\x00\x00\x00\x00http://fr.video.sympatico.ca/accueil/les-plus-populaires/watch/kim-kardashian-rit-des-rumeurs-dinfidelite/2477090497001?sort=date&filter=Splash&page=5
storesFirstKey=\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16
storesLastKey=\xFF\xFF\xFF\xFE\x00\x00\x00\x00http://www.vosclassees.ca/classifieds/-louer/search?p=204&search_type=advanced&filter_recity[cote_saint-luc]=cote_saint-luc&filter_recity[palmerston]=palmerston&filter_recity[richmond_hill]=richmond_hill&filter_recity[thornton]=thornton&filter_recity[new_hamburg]=new_hamburg&filter_recity[shawville]=shawville&filter_recity[kinburn]=kinburn&filter_recity[meaford]=meaford&filter_recity[vancouver]=vancouver&filter_rebathrooms[3]=3
Summary:
-ROOT- is okay.
Number of regions: 1
Deployed on: node1,60020,1377564571051
.META. is okay.
Number of regions: 1
Deployed on: node4,60020,1377564570444
page_proposed is okay.
Number of regions: 16
Deployed on: buldo,60020,1377564571796 node1,60020,1377564571051
node2,60020,1377564571148 node3,60020,1377564569683 node4,60020,1377564570444
node5,60020,1377564564289 node6,60020,1377564570922 node7,60020,1377564570466
tree is okay.
Number of regions: 1
Deployed on: node3,60020,1377564569683
Table work_proposed is inconsistent.
Number of regions: 150
Deployed on: buldo,60020,1377564571796 node1,60020,1377564571051
node2,60020,1377564571148 node3,60020,1377564569683 node4,60020,1377564570444
node5,60020,1377564564289 node6,60020,1377564570922 node7,60020,1377564570466
work_sent is okay.
Number of regions: 16
Deployed on: buldo,60020,1377564571796 node1,60020,1377564571051
node2,60020,1377564571148 node3,60020,1377564569683 node4,60020,1377564570444
node5,60020,1377564564289 node6,60020,1377564570922 node7,60020,1377564570466
1 inconsistencies detected.
Status: INCONSISTENT
{code}
> HBCK should provide an option to check if regions boundaries are the same in
> META and in stores.
>
>
> Key: HBASE-9346
> URL: https://issues.apache.org/jira/browse/HBASE-9346
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 0.95.2, 0.94.11
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
> Attachments: HBASE-9346-v0-0.94.patch
>
>
> If META don't have the same region boundaries as the stores files, writes and
> read might go to the wrong place. We need to provide a way to check that
> withing HBCK.
--
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-8410) Basic quota support for namespaces
[
https://issues.apache.org/jira/browse/HBASE-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vandana Ayyalasomayajula updated HBASE-8410:
Status: Patch Available (was: Open)
> Basic quota support for namespaces
> --
>
> Key: HBASE-8410
> URL: https://issues.apache.org/jira/browse/HBASE-8410
> Project: HBase
> Issue Type: Sub-task
>Reporter: Francis Liu
>Assignee: Vandana Ayyalasomayajula
> Attachments: HBASE_8410_1_trunk.patch, HBASE_8410.patch,
> HBASE-8410_trunk_2.patch, HBASE-8410_trunk_3.patch
>
>
> This task involves creating an observer which provides basic quota support to
> namespaces in terms of (1) number of tables and (2) number of regions. The
> quota support can be enabled by setting:
>
> hbase.coprocessor.region.classes
> org.apache.hadoop.hbase.namespace.NamespaceController
>
>
> hbase.coprocessor.master.classes
> org.apache.hadoop.hbase.namespace.NamespaceController
>
> in the hbase-site.xml.
> To add quotas to namespace, while creating namespace properties need to be
> added.
> Examples:
> 1. namespace_create 'ns1', {'hbase.namespace.quota.maxregion'=>'10'}
> 2. 1. namespace_create 'ns2', {'hbase.namespace.quota.maxtables'=>'2'},
> {'hbase.namespace.quota.maxregion'=>'5'}
> The quotas can be modified/added to namespace at any point of time.
--
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-9343) Implement stateless scanner for Stargate
[ https://issues.apache.org/jira/browse/HBASE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vandana Ayyalasomayajula updated HBASE-9343: Status: Patch Available (was: Open) > Implement stateless scanner for Stargate > > > Key: HBASE-9343 > URL: https://issues.apache.org/jira/browse/HBASE-9343 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 0.94.11 >Reporter: Vandana Ayyalasomayajula >Assignee: Vandana Ayyalasomayajula >Priority: Minor > Attachments: HBASE-9343_94.00.patch > > > The current scanner implementation for scanner stores state and hence not > very suitable for REST server failure scenarios. The current JIRA proposes to > implement a stateless scanner. In the first version of the patch, a new > resource class "ScanResource" has been added and all the scan parameters will > be specified as query params. > The following are the scan parameters > startrow - The start row for the scan. > endrow - The end row for the scan. > columns - The columns to scan. > starttime, endtime - To only retrieve columns within a specific range of > version timestamps,both start and end time must be specified. > maxversions - To limit the number of versions of each column to be returned. > batchsize - To limit the maximum number of values returned for each call to > next(). > limit - The number of rows to return in the scan operation. > More on start row, end row and limit parameters. > 1. If start row, end row and limit not specified, then the whole table will > be scanned. > 2. If start row and limit (say N) is specified, then the scan operation will > return N rows from the start row specified. > 3. If only limit parameter is specified, then the scan operation will return > N rows from the start of the table. > 4. If limit and end row are specified, then the scan operation will return N > rows from start of table till the end row. If the end row is > reached before N rows ( say M and M < N ), then M rows will be returned to > the user. > 5. If start row, end row and limit (say N ) are specified and N < number > of rows between start row and end row, then N rows from start row > will be returned to the user. If N > (number of rows between start row and > end row (say M), then M number of rows will be returned to the > user. -- 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-9347) Support for adding filters for client requests
[ https://issues.apache.org/jira/browse/HBASE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vandana Ayyalasomayajula updated HBASE-9347: Status: Patch Available (was: Open) > Support for adding filters for client requests > -- > > Key: HBASE-9347 > URL: https://issues.apache.org/jira/browse/HBASE-9347 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 0.94.11 >Reporter: Vandana Ayyalasomayajula >Assignee: Vandana Ayyalasomayajula > Attachments: HBASE-9347_94.00.patch > > > Currently there is no support for specifying filters for filtering client > requests. It will be useful if filters can be configured through hbase > configuration. -- 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-9347) Support for adding filters for client requests
Vandana Ayyalasomayajula created HBASE-9347: --- Summary: Support for adding filters for client requests Key: HBASE-9347 URL: https://issues.apache.org/jira/browse/HBASE-9347 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.94.11 Reporter: Vandana Ayyalasomayajula Assignee: Vandana Ayyalasomayajula Attachments: HBASE-9347_94.00.patch Currently there is no support for specifying filters for filtering client requests. It will be useful if filters can be configured through hbase configuration. -- 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-9347) Support for adding filters for client requests
[ https://issues.apache.org/jira/browse/HBASE-9347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vandana Ayyalasomayajula updated HBASE-9347: Attachment: HBASE-9347_94.00.patch Initial draft of the patch. > Support for adding filters for client requests > -- > > Key: HBASE-9347 > URL: https://issues.apache.org/jira/browse/HBASE-9347 > Project: HBase > Issue Type: Improvement > Components: REST >Affects Versions: 0.94.11 >Reporter: Vandana Ayyalasomayajula >Assignee: Vandana Ayyalasomayajula > Attachments: HBASE-9347_94.00.patch > > > Currently there is no support for specifying filters for filtering client > requests. It will be useful if filters can be configured through hbase > configuration. -- 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-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Assignee: chunhui shen (was: Liang Xie)
Release Note: Do a reversed client scan by setting 'reversed' as true in
Scan.Java
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: chunhui shen
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
> row, else will throw exception. Through {@link
> Scan#createBiggestByteArray(int)},you could get a big enough byte array as
> the start row
> All the documentation I find about HBase says that if you want forward and
> reverse scans you should just build 2 tables and one be ascending and one
> descending. Is there a fundamental reason that HBase only supports forward
> Scan? It seems like a lot of extra space overhead and coding overhead (to
> keep them in sync) to support 2 tables.
> I am assuming this has been discussed before, but I can't find the
> discussions anywhere about it or why it would be infeasible.
--
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-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Issue Type: New Feature (was: Improvement)
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: New Feature
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: chunhui shen
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
> row, else will throw exception. Through {@link
> Scan#createBiggestByteArray(int)},you could get a big enough byte array as
> the start row
> All the documentation I find about HBase says that if you want forward and
> reverse scans you should just build 2 tables and one be ascending and one
> descending. Is there a fundamental reason that HBase only supports forward
> Scan? It seems like a lot of extra space overhead and coding overhead (to
> keep them in sync) to support 2 tables.
> I am assuming this has been discussed before, but I can't find the
> discussions anywhere about it or why it would be infeasible.
--
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-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
{format}
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
{/format}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)},you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table',{REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
> row, else will t
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
{format}
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
{format}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> {format}
> hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> {format}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan,
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
{format}
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
{/format}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
{format}
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
{format}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> {format}
> hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> {/format}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
Aslo you could do the reversed scan with shell like this:
hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> Aslo you could do the reversed scan with shell like this:
> hbase> scan 'table', {REVERSED => true,STARTROW=>'ddd', STOPROW=>'bbb'}
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
> row, else will throw exception. Through {@link
> Scan#createBiggestByteArray(int)}, you could get a big enough byte array as
> the start row
>
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward.
And StartRow bigger than StopRow in a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
NOTE: when setting reversed as true for a client scan, you must set the start
row, else will throw exception. Through {@link
Scan#createBiggestByteArray(int)}, you could get a big enough byte array as the
start row
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
Reversed scan means scan the rows backward. And StartRow bigger than StopRow in
a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward.
> And StartRow bigger than StopRow in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> NOTE: when setting reversed as true for a client scan, you must set the start
> row, else will throw exception. Through {@link
> Scan#createBiggestByteArray(int)}, you could get a big enough byte array as
> the start row
> All the documentation I find about HBase says that if you want forward and
> reverse scans you should just build 2 tables and one be ascending and one
> descending. Is there a fundamental reason that HBase only supports forward
> Scan? It seems like a lot of extra space overhead and coding overhead (to
> keep them in sync) to support 2 tables.
> I am assuming this has been discussed before, but I can't find the
> discussions anywhere about it or why it would be i
[jira] [Updated] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chunhui shen updated HBASE-4811:
Description:
Reversed scan means scan the rows backward. And StartRow bigger than StopRow in
a reversed scan.
For example, for the following rows:
aaa/c1:q1/value1
aaa/c1:q2/value2
bbb/c1:q1/value1
bbb/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
ddd/c1:q1/value1
ddd/c1:q2/value2
eee/c1:q1/value1
eee/c1:q2/value2
you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
Scan scan = new Scan();
scan.setStartRow('ddd');
scan.setStopRow('bbb');
scan.setReversed(true);
for(Result result:htable.getScanner(scan)){
System.out.println(result);
}
And the output is:
ddd/c1:q1/value1
ddd/c1:q2/value2
ccc/c1:q1/value1
ccc/c1:q2/value2
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
was:
All the documentation I find about HBase says that if you want forward and
reverse scans you should just build 2 tables and one be ascending and one
descending. Is there a fundamental reason that HBase only supports forward
Scan? It seems like a lot of extra space overhead and coding overhead (to keep
them in sync) to support 2 tables.
I am assuming this has been discussed before, but I can't find the discussions
anywhere about it or why it would be infeasible.
> Support reverse Scan
>
>
> Key: HBASE-4811
> URL: https://issues.apache.org/jira/browse/HBASE-4811
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Affects Versions: 0.20.6, 0.94.7
>Reporter: John Carrino
>Assignee: Liang Xie
> Fix For: 0.98.0
>
> Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt,
> 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt,
> hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch,
> hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch,
> hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch,
> hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch,
> hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch,
> hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch
>
>
> Reversed scan means scan the rows backward. And StartRow bigger than StopRow
> in a reversed scan.
> For example, for the following rows:
> aaa/c1:q1/value1
> aaa/c1:q2/value2
> bbb/c1:q1/value1
> bbb/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> eee/c1:q1/value1
> eee/c1:q2/value2
> you could do a reversed scan from 'ddd' to 'bbb'(exclude) like this:
> Scan scan = new Scan();
> scan.setStartRow('ddd');
> scan.setStopRow('bbb');
> scan.setReversed(true);
> for(Result result:htable.getScanner(scan)){
> System.out.println(result);
> }
> And the output is:
> ddd/c1:q1/value1
> ddd/c1:q2/value2
> ccc/c1:q1/value1
> ccc/c1:q2/value2
> All the documentation I find about HBase says that if you want forward and
> reverse scans you should just build 2 tables and one be ascending and one
> descending. Is there a fundamental reason that HBase only supports forward
> Scan? It seems like a lot of extra space overhead and coding overhead (to
> keep them in sync) to support 2 tables.
> I am assuming this has been discussed before, but I can't find the
> discussions anywhere about it or why it would be infeasible.
--
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-4811) Support reverse Scan
[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-4811: Attachment: hbase-4811-trunkv18.patch Addressing the above Ted's comments and upload it on review board also. https://reviews.apache.org/r/11371/ > Support reverse Scan > > > Key: HBASE-4811 > URL: https://issues.apache.org/jira/browse/HBASE-4811 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.20.6, 0.94.7 >Reporter: John Carrino >Assignee: Liang Xie > Fix For: 0.98.0 > > Attachments: 4811-0.94-v3.txt, 4811-trunk-v10.txt, > 4811-trunk-v5.patch, HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt, > hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, > hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, > hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch, > hbase-4811-trunkv17.patch, hbase-4811-trunkv18.patch, > hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, > hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch > > > All the documentation I find about HBase says that if you want forward and > reverse scans you should just build 2 tables and one be ascending and one > descending. Is there a fundamental reason that HBase only supports forward > Scan? It seems like a lot of extra space overhead and coding overhead (to > keep them in sync) to support 2 tables. > I am assuming this has been discussed before, but I can't find the > discussions anywhere about it or why it would be infeasible. -- 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-9208) ReplicationLogCleaner slow at large scale
[ https://issues.apache.org/jira/browse/HBASE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Latham updated HBASE-9208: --- Attachment: HBASE-9208-v3.patch HBASE-9208-0.94-v2.patch Attaching HBASE-9208-0.94-v2.patch and HBASE-9208-v3.patch. These are new patches for 0.94 and trunk, respectively. They implement the changes discussed above (move the WARN statement to ReplicationLogCleaner.setConf so it only moves once and add the guard clause / remove indentation in CleanerChore.checkAndDeleteEntries) > ReplicationLogCleaner slow at large scale > - > > Key: HBASE-9208 > URL: https://issues.apache.org/jira/browse/HBASE-9208 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Dave Latham >Assignee: Dave Latham > Fix For: 0.94.12, 0.96.0 > > Attachments: HBASE-9208-0.94.patch, HBASE-9208-0.94-v2.patch, > HBASE-9208.patch, HBASE-9208-v2.patch, HBASE-9208-v3.patch > > > At a large scale the ReplicationLogCleaner fails to clean up .oldlogs as fast > as the cluster is producing them. For each old HLog file that has been > replicated and should be deleted the ReplicationLogCleaner checks every > replication queue in ZooKeeper before removing it. This means that as a > cluster scales up the number of files to delete scales as well as the time to > delete each file so the cleanup chore scales quadratically. In our case it > reached the point where the oldlogs were growing faster than they were being > cleaned up. > We're now running with a patch that allows the ReplicationLogCleaner to > refresh its list of files in the replication queues from ZooKeeper just once > for each batch of files the CleanerChore wants to evaluate. > I'd propose updating FileCleanerDelegate to take a List rather > than a single one at a time. This would allow file cleaners that check an > external resource for references such as ZooKeeper (for > ReplicationLogCleaner) or HDFS (for SnapshotLogCleaner which looks like it > may also have similar trouble at scale) to load those references once per > batch rather than for every log. -- 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-9110) Meta region edits not recovered while migrating to 0.96.0
[ https://issues.apache.org/jira/browse/HBASE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750782#comment-13750782 ] Himanshu Vashishtha commented on HBASE-9110: It looks like hbck can help us in situation where meta is not flushed. On a 0.94.x cluster, I tried migration with some unflushed meta edits (basically, create table waledits). I killed the meta server before upgrade. The edits were not there in meta immediately after migration, but appears correctly after running "bin/hbase hbck -fixAssignments, -fixMeta". It definitely needs some more testing. > Meta region edits not recovered while migrating to 0.96.0 > - > > Key: HBASE-9110 > URL: https://issues.apache.org/jira/browse/HBASE-9110 > Project: HBase > Issue Type: Sub-task > Components: migration >Affects Versions: 0.95.2, 0.94.10 >Reporter: Himanshu Vashishtha >Priority: Critical > Fix For: 0.96.0 > > > I was doing the migration testing from 0.94.11-snapshot to 0.95.0, and faced > this issue. > 1) Do some edits in meta table (for eg, create a table). > 2) Kill the cluster. > (I used kill because we would be doing log splitting when upgrading anyway). > 3) There is some dependency on WALs. Upgrade the bits to 0.95.2-snapshot. > Start the cluster. > Every thing comes up. I see log splitting happening as expected. But, the > WAL-data for meta table is missing. > I could see recovered.edits file for meta created, and placed at the right > location. It is just that the new HMaster code tries to recover meta by > looking at meta prefix in the log name, and if it didn't find one, just opens > the meta region. So, the recovered.edits file, created afterwards, is not > honored. > Opening this jira to let folks give their opinions about how to tackle this > migration 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-9342) WebUI fixes after bootstrap 3.0 update
[
https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750778#comment-13750778
]
Hadoop QA commented on HBASE-9342:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600040/HBASE-9342-0.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 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any 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 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6906//console
This message is automatically generated.
> WebUI fixes after bootstrap 3.0 update
> --
>
> Key: HBASE-9342
> URL: https://issues.apache.org/jira/browse/HBASE-9342
> Project: HBase
> Issue Type: Task
> Components: UI
>Affects Versions: 0.98.0, 0.95.2
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9342-0.patch
>
>
--
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-9344) RegionServer not shutting down upon KeeperException in open region
[
https://issues.apache.org/jira/browse/HBASE-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750773#comment-13750773
]
Jimmy Xiang commented on HBASE-9344:
+1
> RegionServer not shutting down upon KeeperException in open region
> --
>
> Key: HBASE-9344
> URL: https://issues.apache.org/jira/browse/HBASE-9344
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
> Attachments: 9344-trunk.txt
>
>
> We ran into a situation where due to a Kerberos configuration problem one of
> our region server could not connect to ZK when opening a region. Instead of
> shutting down it continue to try to reconnect. Eventually the master would
> assign the region to another region server. Each time that region server was
> assigned a region it would sit there for 5 mins with the region offline. It
> would have been better if the region server had shut itself down.
> This is in the logs:
> {quote}
> 2013-08-16 17:31:35,999 WARN org.apache.hadoop.hbase.zookeeper.ZKUtil:
> hconnection-0x2407b842ff2012d-0x2407b842ff2012d-0x2407b842ff2012d Unable to
> set watcher on znode (/hbase/hbaseid)
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode =
> AuthFailed for /hbase/hbaseid
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1041)
> at
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:172)
> at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:450)
> at
> org.apache.hadoop.hbase.zookeeper.ClusterId.readClusterIdZNode(ClusterId.java:61)
> at org.apache.hadoop.hbase.zookeeper.ClusterId.getId(ClusterId.java:50)
> at org.apache.hadoop.hbase.zookeeper.ClusterId.hasId(ClusterId.java:44)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.ensureZookeeperTrackers(HConnectionManager.java:616)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:882)
> at
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:857)
> at org.apache.hadoop.hbase.client.HTable.finishSetup(HTable.java:233)
> at org.apache.hadoop.hbase.client.HTable.(HTable.java:173)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getHTable(MetaReader.java:201)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getMetaHTable(MetaReader.java:227)
> at
> org.apache.hadoop.hbase.catalog.MetaReader.getCatalogHTable(MetaReader.java:214)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.putToCatalogTable(MetaEditor.java:91)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.updateLocation(MetaEditor.java:296)
> at
> org.apache.hadoop.hbase.catalog.MetaEditor.updateRegionLocation(MetaEditor.java:276)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.postOpenDeployTasks(HRegionServer.java:1828)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler$PostOpenDeployTasksThread.run(OpenRegionHandler.java:240)
> {quote}
> I think the RS should shut itself down instead.
--
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-9344) RegionServer not shutting down upon KeeperException in open region
[
https://issues.apache.org/jira/browse/HBASE-9344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750766#comment-13750766
]
Hadoop QA commented on HBASE-9344:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12600036/9344-trunk.txt
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 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6905//console
This message is automatically generated.
> RegionServer not shutting down upon KeeperException in open region
> --
>
> Key: HBASE-9344
> URL: https://issues.apache.org/jira/browse/HBASE-9344
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
> Attachments: 9344-trunk.txt
>
>
> We ran into a situation where due to a Kerberos configuration problem one of
> our region server could not connect to ZK when opening a region. Instead of
> shutting down it continue to try to reconnect. Eventually the master would
> assign the region to another region server. Each time that region server was
> assigned a region it would sit there for 5 mins with the region offline. It
> would have been better if the region server had shut itself down.
> This is in the logs:
> {quote}
> 2013-08-16 17:31:35,999 WARN org.apache.hadoop.hbase.zookeeper.ZKUtil:
> hconnection-0x2407b842ff2012d-0x2407b842ff2012d-0x2407b842ff2012d Unable to
> set watcher on znode (/hbase/hbaseid)
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode =
> AuthFailed for /hbase/hbaseid
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:123)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1041)
> at
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:172)
> at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:450)
> at
> org.apache.hadoop.hbase.zookeeper.ClusterId.readClusterIdZNode(ClusterId.java:61)
> at org.apache.hadoop.hbase.zook
[jira] [Updated] (HBASE-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9342: - Resolution: Fixed Fix Version/s: 0.96.0 0.98.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9342-0.patch > > -- 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-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
[ https://issues.apache.org/jira/browse/HBASE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Marc Spaggiari updated HBASE-9346: --- Attachment: HBASE-9346-v0-0.94.patch Patch for 0.94 attached. Just if someone want to have a look. Not yet tested. Just doing the detection for now. Will upload trunk when 0.94 will be tested. > HBCK should provide an option to check if regions boundaries are the same in > META and in stores. > > > Key: HBASE-9346 > URL: https://issues.apache.org/jira/browse/HBASE-9346 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 0.95.2, 0.94.11 >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Attachments: HBASE-9346-v0-0.94.patch > > > If META don't have the same region boundaries as the stores files, writes and > read might go to the wrong place. We need to provide a way to check that > withing HBCK. -- 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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750747#comment-13750747 ] stack commented on HBASE-9342: -- +1 > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9342-0.patch > > -- 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-7709) Infinite loop possible in Master/Master replication
[ https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750727#comment-13750727 ] Jeffrey Zhong commented on HBASE-7709: -- I reviewed 0.94 and trunk patch. They both looks good to me! +1 from me. Thanks. In the trunk, we currently carry all clusterIds in the replication path and we could optimize this later when there is a need. > Infinite loop possible in Master/Master replication > --- > > Key: HBASE-7709 > URL: https://issues.apache.org/jira/browse/HBASE-7709 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 0.94.6, 0.95.1 >Reporter: Lars Hofhansl >Assignee: Vasu Mariyala > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, > 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, > HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, > HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch > > > We just discovered the following scenario: > # Cluster A and B are setup in master/master replication > # By accident we had Cluster C replicate to Cluster A. > Now all edit originating from C will be bouncing between A and B. Forever! > The reason is that when the edit come in from C the cluster ID is already set > and won't be reset. > We have a couple of options here: > # Optionally only support master/master (not cycles of more than two > clusters). In that case we can always reset the cluster ID in the > ReplicationSource. That means that now cycles > 2 will have the data cycle > forever. This is the only option that requires no changes in the HLog format. > # Instead of a single cluster id per edit maintain a (unordered) set of > cluster id that have seen this edit. Then in ReplicationSource we drop any > edit that the sink has seen already. The is the cleanest approach, but it > might need a lot of data stored per edit if there are many clusters involved. > # Maintain a configurable counter of the maximum cycle side we want to > support. Could default to 10 (even maybe even just). Store a hop-count in the > WAL and the ReplicationSource increases that hop-count on each hop. If we're > over the max, just drop the edit. -- 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-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
[
https://issues.apache.org/jira/browse/HBASE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750722#comment-13750722
]
Jean-Marc Spaggiari commented on HBASE-9346:
Patch will come soon.
Here is an exemple of the output.
{code}
Region's boundaries not alligned between stores and META for:
regionName=work_proposed,\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16,1376139517597.b39bf00b980b632901859761caafb9d0.
metaFirstKey=\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16
metaLastKey=\xF5\x9B@}\x00\x00\x00\x00http://fr.video.sympatico.ca/accueil/les-plus-populaires/watch/kim-kardashian-rit-des-rumeurs-dinfidelite/2477090497001?sort=date&filter=Splash&page=5
storesFirstKey=\xF5\x9A\xEA&\x00\x00\x00\x00http://video.mindentimes.ca/search/all/source/qmi-agency/kanye-west-spending-10-on-private-flights-to-see-pregnant-kim-kardashian/2319156767001/page/16
storesLastKey=\xFF\xFF\xFF\xFE\x00\x00\x00\x00http://www.vosclassees.ca/classifieds/-louer/search?p=204&search_type=advanced&filter_recity[cote_saint-luc]=cote_saint-luc&filter_recity[palmerston]=palmerston&filter_recity[richmond_hill]=richmond_hill&filter_recity[thornton]=thornton&filter_recity[new_hamburg]=new_hamburg&filter_recity[shawville]=shawville&filter_recity[kinburn]=kinburn&filter_recity[meaford]=meaford&filter_recity[vancouver]=vancouver&filter_rebathrooms[3]=3
{code}
> HBCK should provide an option to check if regions boundaries are the same in
> META and in stores.
>
>
> Key: HBASE-9346
> URL: https://issues.apache.org/jira/browse/HBASE-9346
> Project: HBase
> Issue Type: Bug
> Components: hbck
>Affects Versions: 0.95.2, 0.94.11
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>
> If META don't have the same region boundaries as the stores files, writes and
> read might go to the wrong place. We need to provide a way to check that
> withing HBCK.
--
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-9346) HBCK should provide an option to check if regions boundaries are the same in META and in stores.
Jean-Marc Spaggiari created HBASE-9346: -- Summary: HBCK should provide an option to check if regions boundaries are the same in META and in stores. Key: HBASE-9346 URL: https://issues.apache.org/jira/browse/HBASE-9346 Project: HBase Issue Type: Bug Components: hbck Affects Versions: 0.94.11, 0.95.2 Reporter: Jean-Marc Spaggiari Assignee: Jean-Marc Spaggiari If META don't have the same region boundaries as the stores files, writes and read might go to the wrong place. We need to provide a way to check that withing HBCK. -- 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-9338) Test Big Linked List fails on Hadoop 2.1.0
[ https://issues.apache.org/jira/browse/HBASE-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750698#comment-13750698 ] Elliott Clark commented on HBASE-9338: -- I'm also seeing Test Load and Verify fail as well (only with a slowDeterministic chaos monkey). The hard part is that these tests take 3 hours for each run or more. > Test Big Linked List fails on Hadoop 2.1.0 > -- > > Key: HBASE-9338 > URL: https://issues.apache.org/jira/browse/HBASE-9338 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 0.96.0 > > Attachments: HBASE-9338-0.patch > > -- 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-9338) Test Big Linked List fails on Hadoop 2.1.0
[ https://issues.apache.org/jira/browse/HBASE-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750697#comment-13750697 ] Elliott Clark commented on HBASE-9338: -- Unreferenced. I'm running again on top of the tip of 0.95. > Test Big Linked List fails on Hadoop 2.1.0 > -- > > Key: HBASE-9338 > URL: https://issues.apache.org/jira/browse/HBASE-9338 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Fix For: 0.96.0 > > Attachments: HBASE-9338-0.patch > > -- 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-9278) Reading Pre-namespace meta table edits kills the reader
[
https://issues.apache.org/jira/browse/HBASE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Vashishtha updated HBASE-9278:
---
Attachment: HBase-9278-v1.patch
Attached patch adds a test for reading old ROOT, and META edits. I had to add a
new test class as it required SequenceFileLog/Writer(Reader) to write/read the
old entries, in order to simulate reading 0.94.x wal files..
> Reading Pre-namespace meta table edits kills the reader
> ---
>
> Key: HBASE-9278
> URL: https://issues.apache.org/jira/browse/HBASE-9278
> Project: HBase
> Issue Type: Bug
> Components: migration, wal
>Affects Versions: 0.95.2
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBase-9278-v0.patch, HBase-9278-v1.patch
>
>
> In upgrading to 0.96, there might be some meta/root table edits. Currently,
> we are just killing SplitLogWorker thread in case it sees any META, or ROOT
> waledit, which blocks log splitting/replaying of remaining WALs.
> {code}
> 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker
> (SplitLogWorker.java:run(210)) - unexpected error
> java.lang.IllegalArgumentException: .META. no longer exists. The table has
> been renamed to hbase:meta
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
> at
> org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:209)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:138)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.grabTask(SplitLogWorker.java:358)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.taskLoop(SplitLogWorker.java:245)
> at
> org.apache.hadoop.hbase.regionserver.SplitLogWorker.run(SplitLogWorker.java:205)
> at java.lang.Thread.run(Thread.java:662)
> 2013-08-20 15:45:16,999 INFO regionserver.SplitLogWorker
> (SplitLogWorker.java:run(212)) - SplitLogWorker localhost,60020,1377035111898
> exiting
> {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-7462) TestDrainingServer is an integration test. It should be a unit test instead
[ https://issues.apache.org/jira/browse/HBASE-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750686#comment-13750686 ] Gustavo Anatoly commented on HBASE-7462: Ok Nicolas :) don't worry. > TestDrainingServer is an integration test. It should be a unit test instead > --- > > Key: HBASE-7462 > URL: https://issues.apache.org/jira/browse/HBASE-7462 > Project: HBase > Issue Type: Wish > Components: test >Affects Versions: 0.95.2 >Reporter: Nicolas Liochon >Assignee: Gustavo Anatoly >Priority: Trivial > Labels: noob > Attachments: HBASE-7462-v2.patch > > > TestDrainingServer tests the function that allows to say that a regionserver > should not get new regions. > As it is written today, it's an integration test: it starts & stops a cluster. > The test would be more efficient if it would just check that the > AssignmentManager does not use the drained region server; whatever the > circumstances (bulk assign or not for example). -- 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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9342: - Affects Version/s: 0.98.0 0.95.2 Status: Patch Available (was: Open) > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task >Affects Versions: 0.95.2, 0.98.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9342-0.patch > > -- 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-9342) WebUI fixes after bootstrap 3.0 update
[ https://issues.apache.org/jira/browse/HBASE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9342: - Component/s: UI > WebUI fixes after bootstrap 3.0 update > -- > > Key: HBASE-9342 > URL: https://issues.apache.org/jira/browse/HBASE-9342 > Project: HBase > Issue Type: Task > Components: UI >Affects Versions: 0.98.0, 0.95.2 >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-9342-0.patch > > -- 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
