[jira] [Commented] (HBASE-10169) Batch coprocessor
[
https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891896#comment-13891896
]
Hadoop QA commented on HBASE-10169:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627080/HBASE-10169-alternate.patch
against trunk revision .
ATTACHMENT ID: 12627080
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 17 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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 1 release
audit warnings (more than the trunk's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+Pair, List> keysAndRegions =
getKeysAndRegionsInRange(startKey, endKey, true);
+ LOG.trace("Received result for endpoint " +
methodDescriptor.getFullName() + " call #" + originalIndex +
+ ": region=" + Bytes.toStringBinary(region) + ",
row=" + Bytes.toStringBinary(row.getRow()) +
+ (R)
responsePrototype.newBuilderForType().mergeFrom(serviceResult.getValue().getValue()).build());
+ LOG.error("Unexpected response type from endpoint " +
methodDescriptor.getFullName(), e);
+ * Represents a coprocessor service method execution against a single region.
While coprocessor service calls
+ * are performed against a region, this class implements {@link Row} in order
to make use of the {@link AsyncProcess}
+ * {@link
HTable#batchCoprocessorService(com.google.protobuf.Descriptors.MethodDescriptor,
com.google.protobuf.Message, byte[], byte[],
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback,
com.google.protobuf.Message)}
+ * or {@link
HTable#batchCoprocessorService(com.google.protobuf.Descriptors.MethodDescriptor,
com.google.protobuf.Message, byte[], byte[], com.google.protobuf.Message)}
+private CoprocessorServiceResult(boolean noInit) { this.unknownFields =
com.google.protobuf.UnknownFieldSet.getDefaultInstance(); }
{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:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling.testLogRollOnDatanodeDeath(TestLogRolling.java:355)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8602//console
This message is automatically generated.
> Batch coprocessor
> -
>
> Key: HBASE-10169
> URL: https://issues.apache.org/jira/browse/HBASE-10169
> Project: HBase
> Issue Typ
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891887#comment-13891887
]
Hudson commented on HBASE-10460:
SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #123 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/123/])
HBASE-10460 Return value of Scan#setSmall() should be void - Addendum patch to
fix javadoc warning (enis: rev 1564625)
*
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt, hbase-10460_addendum.patch
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891875#comment-13891875
]
Hudson commented on HBASE-10460:
SUCCESS: Integrated in HBase-TRUNK #4886 (See
[https://builds.apache.org/job/HBase-TRUNK/4886/])
HBASE-10460 Return value of Scan#setSmall() should be void - Addendum patch to
fix javadoc warning (enis: rev 1564624)
*
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt, hbase-10460_addendum.patch
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10347) HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes for region replicas
[
https://issues.apache.org/jira/browse/HBASE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891869#comment-13891869
]
Hadoop QA commented on HBASE-10347:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627072/hbase-10347_redo_v6.patch
against trunk revision .
ATTACHMENT ID: 12627072
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 17 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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.master.TestAssignmentManager
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8601//console
This message is automatically generated.
> HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes
> for region replicas
> --
>
> Key: HBASE-10347
> URL: https://issues.apache.org/jira/browse/HBASE-10347
> Project: HBase
> Issue Type: Sub-task
> Components: Region Assignment
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.99.0
>
> Attachments: hbase-10347_redo_v4.patch, hbase-10347_redo_v5.patch,
> hbase-10347_redo_v6.patch
>
>
> As per parent jira, the cleanest way to add region replicas we think is to
> actually create one more region per replica per primary region. So for
> example, if a table has 10 regions with replication = 3, the table would
> indeed be created with 30 regions. These regions will be handled and assigned
> individually for AM purposes.
> We can add replicaId to HRegionInfo to indicate the replicaId, and use this
> to differentiate different replicas of the same region. So, primary replica
> would have replicaId = 0, and the others will have replicaId > 0.
> These replicas will share the same regionId prefix, but differ in an appended
> replicaId. The primary will not contain the replicaId so that no changes
> would be needed for existing tables.
> In meta, the replica regions are kept in the same row as the primary ( so for
> above example, there will be 10 rows in meta). The servers for the replicas
> are kept in columns like "server+replicaId".
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891841#comment-13891841 ] Lars Hofhansl commented on HBASE-10169: --- [~giacomotaylor], we should consider this for Phoenix, when it's done. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate.patch, > HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891840#comment-13891840 ] Lars Hofhansl commented on HBASE-10467: --- It was deprecated in 0.96 so in 0.98 we could remove it (as per own policy). That does not mean we have to remove it of course. At least before 1.0 we should remove it, though. > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10169) Batch coprocessor
[ https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891835#comment-13891835 ] Jingcheng Du commented on HBASE-10169: -- I am having a holiday leave from Sep 29 to Oct 7 with limited access to email. Responses to any email received during this time may be significantly delayed. Sorry for the inconvenience. > Batch coprocessor > - > > Key: HBASE-10169 > URL: https://issues.apache.org/jira/browse/HBASE-10169 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 0.99.0 >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: Batch Coprocessor Design Document.docx, > HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch, > HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate.patch, > HBASE-10169.patch > > > This is designed to improve the coprocessor invocation in the client side. > Currently the coprocessor invocation is to send a call to each region. If > there’s one region server, and 100 regions are located in this server, each > coprocessor invocation will send 100 calls, each call uses a single thread in > the client side. The threads will run out soon when the coprocessor > invocations are heavy. > In this design, all the calls to the same region server will be grouped into > one in a single coprocessor invocation. This call will be spread into each > region in the server side. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-9881) enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console output
[
https://issues.apache.org/jira/browse/HBASE-9881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891834#comment-13891834
]
takeshi.miao commented on HBASE-9881:
-
I will close this ticket if no any concern from anyone, and would send to the
mailing list if I have any question, put such things in jira directly seems the
wrong way to go...sorry to bother you guys here
> enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console
> output
> --
>
> Key: HBASE-9881
> URL: https://issues.apache.org/jira/browse/HBASE-9881
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: takeshi.miao
>Priority: Trivial
>
> Currently, there seems two call paths to determine the value of
> _hbase.root.logger_ in log4j.properties file.
> 1. hbase -> hbase-config.sh -> hbase-env.sh (set _HBASE_ROOT_LOGGER_ if any)
> -> hbase (set default value to HBASE_ROOT_LOGGER if no variable declared)
> 2. hbase-daemon.sh -> hbase-config.sh -> hbase-env.sh (set
> _HBASE_ROOT_LOGGER_ if any) -> hbase-daemon.sh (set default value to
> HBASE_ROOT_LOGGER if no variable declared)
> We found an issue at call path#1, while using 'bin/hbase' the original
> +console output will redirect to the log file+ if the _HBASE_ROOT_LOGGER_
> enabled in hbase-env.sh
> for example
> 1. we use 'bin/hbase zkcli' to connect to zookeeper, will see following log
> output to the console...
> {noformat}
> # bin/hbase zkcli
> Connecting to scottm-hbase-1.lab:2181
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:zookeeper.version=3.4.5-1392090, built on 09/30/2012 17:52 GMT
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:host.name=scottm-hbase-1.lab
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.version=1.6.0_26
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.vendor=Sun Microsystems Inc.
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.home=/usr/java/jdk1.6.0_26/jre
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.class.path=/opt/hbase/bin/../conf:/usr/java/jdk1.6.0_26/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.7.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.4.jar:/opt/hbase/bin/../lib/commons-lang-2.6.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.2.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/findbugs-annotations-1.3.9-1.jar:/opt/hbase/bin/../lib/guava-12.0.1.jar:/opt/hbase/bin/../lib/hadoop-core-1.2.1.jar:/opt/hbase/bin/../lib/hamcrest-core-1.3.jar:/opt/hbase/bin/../lib/hbase-client-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-examples-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop1-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-prefix-tree-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-protocol-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-shell-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-testing-util-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-thrift-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/htrace-core-2.01.jar:/opt/hbase/bin/../lib/httpclient-4.1.3.jar:/opt/hbase/bin/../lib/httpcore-4.1.3.jar:/opt/hbase/bin/../lib/jackson-core-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-jaxrs-1.8.8.jar:/opt/hbase/bin/../lib/jackson-mapper-asl-1.8.8.jar:/opt/hbase/bin/../lib/jackson-xc-1.8.8.jar:/opt/hbase/bin/../lib/jamon-runtime-2.3.1.jar:/opt/hbase/bin/../lib/jasper-compiler-5
[jira] [Updated] (HBASE-10169) Batch coprocessor
[
https://issues.apache.org/jira/browse/HBASE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Helmling updated HBASE-10169:
--
Attachment: HBASE-10169-alternate.patch
After the review I posted on the reviewboard request last week, I went through
the patch and made a number of changes in the direction I had suggested. My
primary comments on the v5 patch were:
{quote}
Thanks for all the work on this updated patch. The new client APIs seem
reasonable, though I think they could use a minor simplification.
My biggest feedback is that MultiRegionServerCallable and
RegionServerCoprocessorRpcInvoker seem to duplicate a lot of what is provided
by the existing MultiServerCallable and AsyncProcess. When I originally looked
at making this same change in a previous version of HBase, I looked at
extending the Action and MultiAction classes to support coprocessor endpoint
invocations so that we could leverage the existing RPC mechanisms. I still
think that would be a better approach here, rather that creating a parallel set
of RPC classes specifically for coprocessor endpoints. But if you disagree,
please just explain what problems you see with this approach.
{quote}
Attached is a modified patch (HBASE-10169-alternate.patch), which modifies the
code to use AsyncProcess as suggested. The main differences from the v5 patch
are:
* In HTable batchCoprocessorService methods, replaces ServiceDescriptor +
String method name with MethodDescriptor
* Removes MultiRegionServerCallable and RegionServerCoprocessorRpcInvoker,
using AsyncProcess instead
* Removes HRegionServer.execMultiService() method
* Removed the additional thread pool in HRegionServer. If this is useful to
have, we could add it back in in a separate issue (and consider doing so for
other batch operations at the same time).
* Adds support for CoprocessorServiceCall to Action/MultiAction, and
CoprocessorServiceResult to MultiResponse/ResultOrException
[~jingcheng...@intel.com], please look through the alternate patch and let me
know if this approach might work for you, or if you still see some needed
functionality missing.
Note: TestBatchCoprocessorEndpoint#testAggregationWithNullResponse seems to be
failing occasionally. I'm still trying to track that down.
> Batch coprocessor
> -
>
> Key: HBASE-10169
> URL: https://issues.apache.org/jira/browse/HBASE-10169
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Affects Versions: 0.99.0
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: Batch Coprocessor Design Document.docx,
> HBASE-10169-V2.patch, HBASE-10169-V3.patch, HBASE-10169-V3.patch,
> HBASE-10169-V4.patch, HBASE-10169-V5.patch, HBASE-10169-alternate.patch,
> HBASE-10169.patch
>
>
> This is designed to improve the coprocessor invocation in the client side.
> Currently the coprocessor invocation is to send a call to each region. If
> there’s one region server, and 100 regions are located in this server, each
> coprocessor invocation will send 100 calls, each call uses a single thread in
> the client side. The threads will run out soon when the coprocessor
> invocations are heavy.
> In this design, all the calls to the same region server will be grouped into
> one in a single coprocessor invocation. This call will be spread into each
> region in the server side.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-9881) enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console output
[
https://issues.apache.org/jira/browse/HBASE-9881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891829#comment-13891829
]
takeshi.miao commented on HBASE-9881:
-
hi [~nijel]
tks for your reply, and for your question the answer as follows...
bq.How this change solved the scenario ? still it will use "INFO,DRFA" right ?
As aforementioned, we use the environment variable to set the
_HBASE_ROOT_LOGGER_
{code}
export HBASE_ROOT_LOGGER="INFO,console"
{code}
But I forgot to describe that we set this variable in the user accounts, not
for hbase account; so for hbase , the related daemons still write their logs
into _DRFA_; for other users, the log will write to console directly.
> enabling HBASE_ROOT_LOGGER in hbase-env.sh would suppress the hbase console
> output
> --
>
> Key: HBASE-9881
> URL: https://issues.apache.org/jira/browse/HBASE-9881
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.96.0
>Reporter: takeshi.miao
>Priority: Trivial
>
> Currently, there seems two call paths to determine the value of
> _hbase.root.logger_ in log4j.properties file.
> 1. hbase -> hbase-config.sh -> hbase-env.sh (set _HBASE_ROOT_LOGGER_ if any)
> -> hbase (set default value to HBASE_ROOT_LOGGER if no variable declared)
> 2. hbase-daemon.sh -> hbase-config.sh -> hbase-env.sh (set
> _HBASE_ROOT_LOGGER_ if any) -> hbase-daemon.sh (set default value to
> HBASE_ROOT_LOGGER if no variable declared)
> We found an issue at call path#1, while using 'bin/hbase' the original
> +console output will redirect to the log file+ if the _HBASE_ROOT_LOGGER_
> enabled in hbase-env.sh
> for example
> 1. we use 'bin/hbase zkcli' to connect to zookeeper, will see following log
> output to the console...
> {noformat}
> # bin/hbase zkcli
> Connecting to scottm-hbase-1.lab:2181
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:zookeeper.version=3.4.5-1392090, built on 09/30/2012 17:52 GMT
> 2013-11-04 08:33:39,855 INFO [main] zookeeper.ZooKeeper: Client
> environment:host.name=scottm-hbase-1.lab
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.version=1.6.0_26
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.vendor=Sun Microsystems Inc.
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.home=/usr/java/jdk1.6.0_26/jre
> 2013-11-04 08:33:39,856 INFO [main] zookeeper.ZooKeeper: Client
> environment:java.class.path=/opt/hbase/bin/../conf:/usr/java/jdk1.6.0_26/lib/tools.jar:/opt/hbase/bin/..:/opt/hbase/bin/../lib/activation-1.1.jar:/opt/hbase/bin/../lib/asm-3.1.jar:/opt/hbase/bin/../lib/commons-beanutils-1.7.0.jar:/opt/hbase/bin/../lib/commons-beanutils-core-1.8.0.jar:/opt/hbase/bin/../lib/commons-cli-1.2.jar:/opt/hbase/bin/../lib/commons-codec-1.7.jar:/opt/hbase/bin/../lib/commons-collections-3.2.1.jar:/opt/hbase/bin/../lib/commons-configuration-1.6.jar:/opt/hbase/bin/../lib/commons-digester-1.8.jar:/opt/hbase/bin/../lib/commons-el-1.0.jar:/opt/hbase/bin/../lib/commons-httpclient-3.1.jar:/opt/hbase/bin/../lib/commons-io-2.4.jar:/opt/hbase/bin/../lib/commons-lang-2.6.jar:/opt/hbase/bin/../lib/commons-logging-1.1.1.jar:/opt/hbase/bin/../lib/commons-math-2.2.jar:/opt/hbase/bin/../lib/commons-net-1.4.1.jar:/opt/hbase/bin/../lib/core-3.1.1.jar:/opt/hbase/bin/../lib/findbugs-annotations-1.3.9-1.jar:/opt/hbase/bin/../lib/guava-12.0.1.jar:/opt/hbase/bin/../lib/hadoop-core-1.2.1.jar:/opt/hbase/bin/../lib/hamcrest-core-1.3.jar:/opt/hbase/bin/../lib/hbase-client-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-common-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-examples-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop1-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-hadoop-compat-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-it-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-prefix-tree-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-protocol-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-server-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT-tests.jar:/opt/hbase/bin/../lib/hbase-shell-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-testing-util-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/hbase-thrift-0.97.0-hadoop1-SNAPSHOT-SNAPSHOT.jar:/opt/hbase/bin/../lib/high-scale-lib-1.1.1.jar:/opt/hbase/bin/../lib/htrace-core-2.01.jar:/opt/hbase/bin/../lib/httpclient-4.1.3.jar:/
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Fix Version/s: (was: 0.99.0) Reverted patch v3 from trunk. > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891822#comment-13891822
]
Hadoop QA commented on HBASE-10277:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627062/HBASE-10277.07.patch
against trunk revision .
ATTACHMENT ID: 12627062
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 2
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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ * See {@link #submit(ExecutorService, TableName, List, boolean,
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback, boolean)}.
+ boolean atLeastOne, Batch.Callback callback, boolean
needResults) throws InterruptedIOException {
+ // This action failed before creating ars. Add it to retained but do
not add to submit list.
+ * See {@link #submitAll(ExecutorService, TableName, List,
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback, Object[])}.
+" Retrying. Server is " + server.getServerName() + ",
tableName=" + tableName, t);
+ Throwable error, long backOffTime, boolean
willRetry, String startTime){
{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/8600//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8600//console
This message is automatically generated.
> refactor AsyncProcess
> -
>
> Key: HBASE-10277
> URL: https://issues.apache.org/jira/browse/HBASE-10277
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch,
> HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch,
> HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch
>
>
> AsyncProcess currently has two patterns of usage, one from HTable flush w/o
> callback and with reuse, and one from HCM/HTable batch call, with callback
> and w/o reuse. In the former case (but not the latter), it also does some
> throttling of actions on initial submit call, limiting the number of
> outstanding actions per server.
> The latter case is relatively straightforward. The former appears to be error
> prone due to reuse - if, as javadoc claims should be safe, multiple submit
> calls are performed without waiting for the async part of the previous call
> to finish, fields like hasError become ambiguous and can be used for the
> wrong call; callback for succ
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891814#comment-13891814 ] Anoop Sam John commented on HBASE-10467: This patch restores the reprecated API in 0.99 also. Atleast from that version the deprecated API should be removed? > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891813#comment-13891813 ] Anoop Sam John commented on HBASE-10467: bq.These were deprecated in 0.96 and we should remove them now (rather than renaming and/or restoring them). So when we make some API deprecated in one version, when we can remove this? I was thinking that we can remove it in next major version. I am also having the same feeling as what Lars said above. Pls correct if I am wrong. > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891809#comment-13891809 ] Hudson commented on HBASE-10467: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #122 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/122/]) HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564594) * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRollAbort.java HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564593) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564589) * /hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java * /hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestDurability.java > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10469) Hbase book client.html has a broken link
Vivek Ganesan created HBASE-10469: - Summary: Hbase book client.html has a broken link Key: HBASE-10469 URL: https://issues.apache.org/jira/browse/HBASE-10469 Project: HBase Issue Type: Bug Environment: URL : http://hbase.apache.org/book/client.html Reporter: Vivek Ganesan Priority: Minor In section 9.3.2 - WriteBuffer and Batch Methods, the link "ACID semantics" is broken. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
[ https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891799#comment-13891799 ] stack commented on HBASE-10465: --- +1 Go even more while you are at it on commit [~jxiang] > TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes > --- > > Key: HBASE-10465 > URL: https://issues.apache.org/jira/browse/HBASE-10465 > Project: HBase > Issue Type: Test >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Trivial > Attachments: hbase-10465.patch > > > It looks like sleeping 100 ms is not enough for the permission change to > propagate to other watchers. Will increase the sleeping time a little. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891703#comment-13891703 ] Hudson commented on HBASE-10467: SUCCESS: Integrated in HBase-TRUNK #4885 (See [https://builds.apache.org/job/HBase-TRUNK/4885/]) HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564591) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestDurability.java > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset
[ https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891699#comment-13891699 ] stack commented on HBASE-10447: --- Thanks [~ram_krish] > Memstore flusher scans storefiles also when the scanner heap gets reset > --- > > Key: HBASE-10447 > URL: https://issues.apache.org/jira/browse/HBASE-10447 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 0.99.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, > HBASE-10447_trunk_1.patch > > > See the mail thread > http://osdir.com/ml/general/2014-01/msg61294.html > In case of flush we create a memstore flusher which in turn creates a > StoreScanner backed by a Single ton MemstoreScanner. > But this scanner also registers for any updates in the reader in the HStore. > Is this needed? > If this happens then any update on the reader may nullify the current heap > and the entire Scanner Stack is reset, but this time with the other scanners > for all the files that satisfies the last top key. So the flush that happens > on the memstore holds the storefile scanners also in the heap that was > recreated but originally the intention was to create a scanner on the > memstore alone. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10347) HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes for region replicas
[ https://issues.apache.org/jira/browse/HBASE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-10347: -- Attachment: hbase-10347_redo_v6.patch Thanks for reviews. With Stack's and Sergey's +1's I think this is almost ready to be committed to branch. v6 version addressed the UT failure and javadoc warnings. I might have to do another rebase after HBASE-10277 is in trunk, but it should be straightforward. > HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes > for region replicas > -- > > Key: HBASE-10347 > URL: https://issues.apache.org/jira/browse/HBASE-10347 > Project: HBase > Issue Type: Sub-task > Components: Region Assignment >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.99.0 > > Attachments: hbase-10347_redo_v4.patch, hbase-10347_redo_v5.patch, > hbase-10347_redo_v6.patch > > > As per parent jira, the cleanest way to add region replicas we think is to > actually create one more region per replica per primary region. So for > example, if a table has 10 regions with replication = 3, the table would > indeed be created with 30 regions. These regions will be handled and assigned > individually for AM purposes. > We can add replicaId to HRegionInfo to indicate the replicaId, and use this > to differentiate different replicas of the same region. So, primary replica > would have replicaId = 0, and the others will have replicaId > 0. > These replicas will share the same regionId prefix, but differ in an appended > replicaId. The primary will not contain the replicaId so that no changes > would be needed for existing tables. > In meta, the replica regions are kept in the same row as the primary ( so for > above example, there will be 10 rows in meta). The servers for the replicas > are kept in columns like "server+replicaId". -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891689#comment-13891689
]
Ted Yu commented on HBASE-10460:
Thanks, Enis.
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt, hbase-10460_addendum.patch
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-10460:
--
Attachment: hbase-10460_addendum.patch
I just committed this addendum to fix javadoc warning after the patch.
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt, hbase-10460_addendum.patch
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset
[ https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891671#comment-13891671 ] ramkrishna.s.vasudevan commented on HBASE-10447: Not needed in 0.96. It is fine there. That is why removed the fix/affected versions as 0.96. > Memstore flusher scans storefiles also when the scanner heap gets reset > --- > > Key: HBASE-10447 > URL: https://issues.apache.org/jira/browse/HBASE-10447 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 0.99.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, > HBASE-10447_trunk_1.patch > > > See the mail thread > http://osdir.com/ml/general/2014-01/msg61294.html > In case of flush we create a memstore flusher which in turn creates a > StoreScanner backed by a Single ton MemstoreScanner. > But this scanner also registers for any updates in the reader in the HStore. > Is this needed? > If this happens then any update on the reader may nullify the current heap > and the entire Scanner Stack is reset, but this time with the other scanners > for all the files that satisfies the last top key. So the flush that happens > on the memstore holds the storefile scanners also in the heap that was > recreated but originally the intention was to create a scanner on the > memstore alone. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10277: - Attachment: HBASE-10277.07.patch test code fix > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891635#comment-13891635
]
Hudson commented on HBASE-10460:
SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #121 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/121/])
HBASE-10460 Return value of Scan#setSmall() should be void (tedyu: rev 1564560)
*
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (HBASE-10217) SlabCache size logging on initialization is wrong
[
https://issues.apache.org/jira/browse/HBASE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v reassigned HBASE-10217:
-
Assignee: bharath v
> SlabCache size logging on initialization is wrong
> -
>
> Key: HBASE-10217
> URL: https://issues.apache.org/jira/browse/HBASE-10217
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.99.0
>Reporter: Nick Dimiduk
>Assignee: bharath v
>Priority: Trivial
> Labels: noob
>
> From the logs:
> {noformat}
> 2013-12-17 23:57:40,060 INFO [main] slab.SlabCache: Creating a slab of
> blockSize 72089 with 140233 blocks, 1.4 Gbytes.
> 2013-12-17 23:57:43,622 INFO [main] slab.SlabCache: Creating a slab of
> blockSize 137625 with 18363 blocks, -1.6 Gbytes.
> {noformat}
> By my math, these values should be 9.4G and 2.4G respectively.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891618#comment-13891618 ] Lars Hofhansl commented on HBASE-10467: --- Wait now. We should remove this API. We have a new API (setDurability) that subsumes this. These were deprecated in 0.96 and we should remove them now (rather than renaming and/or restoring them). That's exactly the discussion we had on the mailing list. No need to hold a release or anything, but this should be removed, if we do not do this now we'll have to wait until 1.0. A whimpering -0 from me. :) > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10459) Broken link F.1. HBase Videos
[ https://issues.apache.org/jira/browse/HBASE-10459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891615#comment-13891615 ] Hudson commented on HBASE-10459: SUCCESS: Integrated in HBase-TRUNK #4884 (See [https://builds.apache.org/job/HBase-TRUNK/4884/]) HBASE-10459 [docs] Broken link F.1. HBase Videos (Richard Shaw) (jmhsieh: rev 1564555) * /hbase/trunk/src/main/docbkx/book.xml > Broken link F.1. HBase Videos > - > > Key: HBASE-10459 > URL: https://issues.apache.org/jira/browse/HBASE-10459 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Richard Shaw >Assignee: Richard Shaw >Priority: Trivial > Labels: documentation > Fix For: 0.99.0 > > Attachments: book_HBASE_10459.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Broken link to first introduction to HBase video [0] > Second Introduction video works, so suspect a redirect at the other end is > broken or it's being changed in which case the second may stop working as > well. > Have supplied a patch > [0]https://hbase.apache.org/book.html#other.info.videos -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891614#comment-13891614
]
Hudson commented on HBASE-10460:
SUCCESS: Integrated in HBase-TRUNK #4884 (See
[https://builds.apache.org/job/HBase-TRUNK/4884/])
HBASE-10460 Return value of Scan#setSmall() should be void (tedyu: rev 1564561)
*
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891597#comment-13891597 ] Sergey Shelukhin commented on HBASE-10277: -- yeah NPE because mocj doesn't override newly added reusable AP. I'll see what can be done, probably just create new API in the mock. I'd assume +1s would stand with that change, so I'd commit late today or tomorrow > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891594#comment-13891594
]
Hudson commented on HBASE-10460:
SUCCESS: Integrated in HBase-0.98 #129 (See
[https://builds.apache.org/job/HBase-0.98/129/])
HBASE-10460 Return value of Scan#setSmall() should be void (tedyu: rev 1564560)
*
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891584#comment-13891584 ] Sergey Shelukhin commented on HBASE-10277: -- probably another mock-related failure... let me investigate > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891572#comment-13891572
]
Hadoop QA commented on HBASE-10277:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12627021/HBASE-10277.06.patch
against trunk revision .
ATTACHMENT ID: 12627021
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 3
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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ * See {@link #submit(ExecutorService, TableName, List, boolean,
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback, boolean)}.
+ boolean atLeastOne, Batch.Callback callback, boolean
needResults) throws InterruptedIOException {
+ // This action failed before creating ars. Add it to retained but do
not add to submit list.
+ * See {@link #submitAll(ExecutorService, TableName, List,
org.apache.hadoop.hbase.client.coprocessor.Batch.Callback, Object[])}.
+" Retrying. Server is " + server.getServerName() + ",
tableName=" + tableName, t);
+ Throwable error, long backOffTime, boolean
willRetry, String startTime){
{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.master.TestCatalogJanitor
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8598//console
This message is automatically generated.
> refactor AsyncProcess
> -
>
> Key: HBASE-10277
> URL: https://issues.apache.org/jira/browse/HBASE-10277
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch,
> HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch,
> HBASE-10277.06.patch, HBASE-10277.patch
>
>
> AsyncProcess currently has two patterns of usage, one from HTable flush w/o
> callback and with reuse, and one from HCM/HTable batch call, with callback
> and w/o reuse. In the former case (but not the latter), it also does some
> throttling of actions on initial submit call, limiting the number of
> outstanding actions per server.
> The latter case is relatively straightforward. The former appears to be error
> prone due to reuse - if, as javadoc claims should be safe, multiple submit
> calls are performed without waiting for the async part of the previous call
> to finish, fields like hasError become ambiguous and
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891564#comment-13891564 ] Hudson commented on HBASE-10457: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #79 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/79/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564425) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset
[ https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891565#comment-13891565 ] Hudson commented on HBASE-10447: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #79 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/79/]) HBASE-10447-Memstore flusher scans storefiles also when the scanner heap gets resetKVHeap(Ram) (ramkrishna: rev 1564377) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Memstore flusher scans storefiles also when the scanner heap gets reset > --- > > Key: HBASE-10447 > URL: https://issues.apache.org/jira/browse/HBASE-10447 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 0.99.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, > HBASE-10447_trunk_1.patch > > > See the mail thread > http://osdir.com/ml/general/2014-01/msg61294.html > In case of flush we create a memstore flusher which in turn creates a > StoreScanner backed by a Single ton MemstoreScanner. > But this scanner also registers for any updates in the reader in the HStore. > Is this needed? > If this happens then any update on the reader may nullify the current heap > and the entire Scanner Stack is reset, but this time with the other scanners > for all the files that satisfies the last top key. So the flush that happens > on the memstore holds the storefile scanners also in the heap that was > recreated but originally the intention was to create a scanner on the > memstore alone. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used
[ https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891563#comment-13891563 ] Hudson commented on HBASE-10454: FAILURE: Integrated in HBase-TRUNK-on-Hadoop-1.1 #79 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/79/]) HBASE-10454 Tags presence file info can be wrong in HFiles when PrefixTree encoding is used. (anoopsamjohn: rev 1564384) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV3.java > Tags presence file info can be wrong in HFiles when PrefixTree encoding is > used > --- > > Key: HBASE-10454 > URL: https://issues.apache.org/jira/browse/HBASE-10454 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10454.patch, HBASE-10454_V2.patch > > > We always encode tags in case of Prefix tree now and so the code path, while > decoding, not checking what is there in FileInfo. So functionally no issues > now. > If we do HBASE-10453 this change will be very important to make sure BC for > old files. > We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In > case of prefix tree we always have tags in files even if all kvs have 0 tags. > So better we can add this file info into prefix tree encoded HFiles. Now it > get missed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Hadoop Flags: Reviewed Integrated to 0.98 and trunk. Ran TestDurability in 0.98 and trunk which passed. Thanks Enis and Andy for the reviews. > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10447) Memstore flusher scans storefiles also when the scanner heap gets reset
[ https://issues.apache.org/jira/browse/HBASE-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891543#comment-13891543 ] stack commented on HBASE-10447: --- I'm good w/ this in 0.96. I tried to apply the 0.98 but it fails. Thanks. > Memstore flusher scans storefiles also when the scanner heap gets reset > --- > > Key: HBASE-10447 > URL: https://issues.apache.org/jira/browse/HBASE-10447 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0, 0.99.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10447_0.98.patch, HBASE-10447_trunk.patch, > HBASE-10447_trunk_1.patch > > > See the mail thread > http://osdir.com/ml/general/2014-01/msg61294.html > In case of flush we create a memstore flusher which in turn creates a > StoreScanner backed by a Single ton MemstoreScanner. > But this scanner also registers for any updates in the reader in the HStore. > Is this needed? > If this happens then any update on the reader may nullify the current heap > and the entire Scanner Stack is reset, but this time with the other scanners > for all the files that satisfies the last top key. So the flush that happens > on the memstore holds the storefile scanners also in the heap that was > recreated but originally the intention was to create a scanner on the > memstore alone. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Summary: Restore HTableDescriptor#isDeferredLogFlush() (was: Restore HTableDescriptor#isDeferredLogFlush() in 0.98) > Restore HTableDescriptor#isDeferredLogFlush() > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891526#comment-13891526 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #120 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/120/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564427) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
[
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891523#comment-13891523
]
Hadoop QA commented on HBASE-10465:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12626993/hbase-10465.patch
against trunk revision .
ATTACHMENT ID: 12626993
{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 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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/8597//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8597//console
This message is automatically generated.
> TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
> ---
>
> Key: HBASE-10465
> URL: https://issues.apache.org/jira/browse/HBASE-10465
> Project: HBase
> Issue Type: Test
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
>Priority: Trivial
> Attachments: hbase-10465.patch
>
>
> It looks like sleeping 100 ms is not enough for the permission change to
> propagate to other watchers. Will increase the sleeping time a little.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used
[ https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891525#comment-13891525 ] Hudson commented on HBASE-10454: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #120 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/120/]) HBASE-10454 Tags presence file info can be wrong in HFiles when PrefixTree encoding is used. (anoopsamjohn: rev 1564385) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV3.java > Tags presence file info can be wrong in HFiles when PrefixTree encoding is > used > --- > > Key: HBASE-10454 > URL: https://issues.apache.org/jira/browse/HBASE-10454 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10454.patch, HBASE-10454_V2.patch > > > We always encode tags in case of Prefix tree now and so the code path, while > decoding, not checking what is there in FileInfo. So functionally no issues > now. > If we do HBASE-10453 this change will be very important to make sure BC for > old files. > We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In > case of prefix tree we always have tags in files even if all kvs have 0 tags. > So better we can add this file info into prefix tree encoded HFiles. Now it > get missed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891521#comment-13891521 ] Andrew Purtell commented on HBASE-10467: +1 > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-10467: -- Fix Version/s: 0.99.0 > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891511#comment-13891511 ] Enis Soztutar commented on HBASE-10467: --- Thanks Ted. +1 for trunk and 0.98. [~andrew.purt...@gmail.com] do you want to check it for 0.98? > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891509#comment-13891509 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in hbase-0.96-hadoop2 #193 (See [https://builds.apache.org/job/hbase-0.96-hadoop2/193/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564428) * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10468) refactor AsyncProcess pt 2
Sergey Shelukhin created HBASE-10468: Summary: refactor AsyncProcess pt 2 Key: HBASE-10468 URL: https://issues.apache.org/jira/browse/HBASE-10468 Project: HBase Issue Type: Improvement Reporter: Sergey Shelukhin Followup for HBASE-10277. Further work can be done, as discussed in comments, such as moving "global" error management for streaming use case from AsyncProcess to HTable. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10389) Add namespace help info in table related shell commands
[
https://issues.apache.org/jira/browse/HBASE-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891488#comment-13891488
]
Jerry He commented on HBASE-10389:
--
All the following work as desired:
hbase> disable_all 't.*'
hbase> disable_all 'ns:t.*'
hbase> disable_all 'ns:.*'
and this one will include my_namespace1:table1, my_namespace2:table2, my_table
hbase> disable_all 'my.*'
> Add namespace help info in table related shell commands
> ---
>
> Key: HBASE-10389
> URL: https://issues.apache.org/jira/browse/HBASE-10389
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0, 0.96.1
>Reporter: Jerry He
>Assignee: Jerry He
> Attachments: HBASE-10389-trunk.patch
>
>
> Currently in the help info of table related shell command, we don't mention
> or give namespace as part of the table name.
> For example, to create table:
> {code}
> hbase(main):001:0> help 'create'
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily
> including NAME attribute.
> Examples:
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}
> hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
> hbase> # The above in shorthand would be the following:
> hbase> create 't1', 'f1', 'f2', 'f3'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000,
> BLOCKCACHE => true}
> hbase> create 't1', {NAME => 'f1', CONFIGURATION =>
> {'hbase.hstore.blockingStoreFiles' => '10'}}
> Table configuration options can be put at the end.
> Examples:
> hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
> hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' =>
> 'myvalue' }
> hbase> # Optionally pre-split the table into NUMREGIONS, using
> hbase> # SPLITALGO ("HexStringSplit", "UniformSplit" or classname)
> hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
> hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit',
> CONFIGURATION => {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}}
> You can also keep around a reference to the created table:
> hbase> t1 = create 't1', 'f1'
> Which gives you a reference to the table named 't1', on which you can then
> call methods.
> {code}
> We should document the usage of namespace in these commands.
> For example:
> #namespace=foo and table qualifier=bar
> create 'foo:bar', 'fam'
> #namespace=default and table qualifier=bar
> create 'bar', 'fam'
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Attachment: 10467-v3.txt How about patch v3 ? > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0 > > Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891470#comment-13891470
]
Enis Soztutar commented on HBASE-10467:
---
I mean the java annotation, together with the javadoc:
{code}
@Deprecated
{code}
> Restore HTableDescriptor#isDeferredLogFlush() in 0.98
> -
>
> Key: HBASE-10467
> URL: https://issues.apache.org/jira/browse/HBASE-10467
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 10467-v2.txt, 10467.txt
>
>
> HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked
> Deprecated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891465#comment-13891465
]
Ted Yu commented on HBASE-10467:
It is deprecated:
{code}
* @deprecated Since 0.96 we no longer have an explicity deferred log
flush/sync functionality.
{code}
> Restore HTableDescriptor#isDeferredLogFlush() in 0.98
> -
>
> Key: HBASE-10467
> URL: https://issues.apache.org/jira/browse/HBASE-10467
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 10467-v2.txt, 10467.txt
>
>
> HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked
> Deprecated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Fix Version/s: (was: 0.99.0) > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891463#comment-13891463 ] Enis Soztutar commented on HBASE-10467: --- Can you also put the deprecated annotation in isDeferredLogFlush(). Other than that +1. > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Attachment: (was: 10467-v2.txt) > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891455#comment-13891455 ] Sergey Shelukhin commented on HBASE-10277: -- I will file a follow-up JIRA. Responded on RB, but it now gives me errors, not sure if it got posted. The answer is "yes". > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Attachment: 10467-v2.txt > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Attachment: 10467-v2.txt Patch v2 addresses Enis' comments. > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891434#comment-13891434
]
Enis Soztutar commented on HBASE-10467:
---
Basically undo the patch at HBASE-10324 for HTD:
{code}
- @Deprecated
- public synchronized boolean isDeferredLogFlush() {
+ public synchronized boolean isAsyncLogFlush() {
return getDurability() == Durability.ASYNC_WAL;
}
- @Deprecated
- public synchronized void setDeferredLogFlush(final boolean
isDeferredLogFlush) {
-this.setDurability(isDeferredLogFlush ? Durability.ASYNC_WAL :
DEFAULT_DURABLITY);
+ public synchronized void setAsyncLogFlush(final boolean isAsyncLogFlush) {
+this.setDurability(isAsyncLogFlush ? Durability.ASYNC_WAL :
DEFAULT_DURABLITY);
}
{code}
We should add the @Deprecated annotations as well.
> Restore HTableDescriptor#isDeferredLogFlush() in 0.98
> -
>
> Key: HBASE-10467
> URL: https://issues.apache.org/jira/browse/HBASE-10467
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10467.txt
>
>
> HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked
> Deprecated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu resolved HBASE-10460.
Resolution: Fixed
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible
[
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891441#comment-13891441
]
Hadoop QA commented on HBASE-10337:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12626968/10337.v2.patch
against trunk revision .
ATTACHMENT ID: 12626968
{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 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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 1 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/8596//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8596//console
This message is automatically generated.
> HTable.get() uninteruptible
> ---
>
> Key: HBASE-10337
> URL: https://issues.apache.org/jira/browse/HBASE-10337
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
>Reporter: Jonathan Leech
>Assignee: Nicolas Liochon
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10337.v1.patch, 10337.v2.patch
>
>
> I've got a stuck thread on HTable.get() that can't be interrupted, looks like
> its designed to be interruptible but can't be in interrupted in practice due
> to while loop.
> The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line
> 981, it catches InterruptedException then goes right back to waiting due to
> the while loop.
> It looks like future versions of the client (.95+) are significantly
> different and might not have this problem... Not sure about release schedules
> etc. or if this version is still getting patched.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Status: Patch Available (was: Open) > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467-v2.txt, 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891437#comment-13891437
]
Lars Hofhansl commented on HBASE-10460:
---
I think if it's easy to do we might as well maintain binary compatibility. It
wouldn't have sunk an RC (IMHO), but because there is no current RC anyway,
might as well change it.
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Attachment: 10467.txt Patch for 0.98 > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-10467: --- Fix Version/s: 0.99.0 0.98.0 > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891428#comment-13891428 ] Enis Soztutar commented on HBASE-10467: --- We actually want to rename isAsyncLogFlush() -> isDeferredLogFlush(), and setAsyncLogFlush() -> setDeferredLogFlush() > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 0.98.0, 0.99.0 > > Attachments: 10467.txt > > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891422#comment-13891422 ] Enis Soztutar commented on HBASE-10277: --- bq. Wrt moving error management for streaming mode out of AsyncProcess, for example into HTable, I think it might hurt performance because HTable will have to manage all these objects. Let me try to think if this can be avoided. Ok, we can address that as a follow up if there is benefit in abstracting that away. One small question in RB, other than that I'm +1 as well. > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
[ https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu reassigned HBASE-10467: -- Assignee: Ted Yu > Restore HTableDescriptor#isDeferredLogFlush() in 0.98 > - > > Key: HBASE-10467 > URL: https://issues.apache.org/jira/browse/HBASE-10467 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > > HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked > Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891421#comment-13891421 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in HBase-0.98 #128 (See [https://builds.apache.org/job/HBase-0.98/128/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564427) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used
[ https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891420#comment-13891420 ] Hudson commented on HBASE-10454: SUCCESS: Integrated in HBase-0.98 #128 (See [https://builds.apache.org/job/HBase-0.98/128/]) HBASE-10454 Tags presence file info can be wrong in HFiles when PrefixTree encoding is used. (anoopsamjohn: rev 1564385) * /hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV3.java > Tags presence file info can be wrong in HFiles when PrefixTree encoding is > used > --- > > Key: HBASE-10454 > URL: https://issues.apache.org/jira/browse/HBASE-10454 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10454.patch, HBASE-10454_V2.patch > > > We always encode tags in case of Prefix tree now and so the code path, while > decoding, not checking what is there in FileInfo. So functionally no issues > now. > If we do HBASE-10453 this change will be very important to make sure BC for > old files. > We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In > case of prefix tree we always have tags in files even if all kvs have 0 tags. > So better we can add this file info into prefix tree encoded HFiles. Now it > get missed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush() in 0.98
Ted Yu created HBASE-10467: -- Summary: Restore HTableDescriptor#isDeferredLogFlush() in 0.98 Key: HBASE-10467 URL: https://issues.apache.org/jira/browse/HBASE-10467 Project: HBase Issue Type: Bug Reporter: Ted Yu HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked Deprecated. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891417#comment-13891417 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in HBase-TRUNK #4883 (See [https://builds.apache.org/job/HBase-TRUNK/4883/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564425) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891415#comment-13891415
]
Andrew Purtell commented on HBASE-10460:
Like I said above I closed this because it was predicated on an RC criteria
that didn't exist. I have no objection to the change itself if people think it
is a good idea.
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-10460:
---
Fix Version/s: 0.99.0
Hadoop Flags: Reviewed
Integrated to 0.98 and trunk.
Thanks Jon.
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.99.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10277) refactor AsyncProcess
[ https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-10277: - Attachment: HBASE-10277.06.patch Address Nicolas' feedback from RB, and one TODO, now AP is shared in HConnection, I added an option to have pool either in AP or in individual request > refactor AsyncProcess > - > > Key: HBASE-10277 > URL: https://issues.apache.org/jira/browse/HBASE-10277 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, > HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, > HBASE-10277.06.patch, HBASE-10277.patch > > > AsyncProcess currently has two patterns of usage, one from HTable flush w/o > callback and with reuse, and one from HCM/HTable batch call, with callback > and w/o reuse. In the former case (but not the latter), it also does some > throttling of actions on initial submit call, limiting the number of > outstanding actions per server. > The latter case is relatively straightforward. The former appears to be error > prone due to reuse - if, as javadoc claims should be safe, multiple submit > calls are performed without waiting for the async part of the previous call > to finish, fields like hasError become ambiguous and can be used for the > wrong call; callback for success/failure is called based on "original index" > of an action in submitted list, but with only one callback supplied to AP in > ctor it's not clear to which submit call the index belongs, if several are > outstanding. > I was going to add support for HBASE-10070 to AP, and found that it might be > difficult to do cleanly. > It would be nice to normalize AP usage patterns; in particular, separate the > "global" part (load tracking) from per-submit-call part. > Per-submit part can more conveniently track stuff like initialActions, > mapping of indexes and retry information, that is currently passed around the > method calls. > -I am not sure yet, but maybe sending of the original index to server in > "ClientProtos.MultiAction" can also be avoided.- Cannot be avoided because > the API to server doesn't have one-to-one correspondence between requests and > responses in an individual call to multi (retries/rearrangement have nothing > to do with it) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10459) Broken link F.1. HBase Videos
[ https://issues.apache.org/jira/browse/HBASE-10459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10459: --- Tags: (was: broken link) Resolution: Fixed Fix Version/s: 0.99.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committing to trunk. Thanks for the patch Richard! > Broken link F.1. HBase Videos > - > > Key: HBASE-10459 > URL: https://issues.apache.org/jira/browse/HBASE-10459 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Richard Shaw >Assignee: Richard Shaw >Priority: Trivial > Labels: documentation > Fix For: 0.99.0 > > Attachments: book_HBASE_10459.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Broken link to first introduction to HBase video [0] > Second Introduction video works, so suspect a redirect at the other end is > broken or it's being changed in which case the second may stop working as > well. > Have supplied a patch > [0]https://hbase.apache.org/book.html#other.info.videos -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10459) Broken link F.1. HBase Videos
[ https://issues.apache.org/jira/browse/HBASE-10459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-10459: --- Assignee: Richard Shaw > Broken link F.1. HBase Videos > - > > Key: HBASE-10459 > URL: https://issues.apache.org/jira/browse/HBASE-10459 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Richard Shaw >Assignee: Richard Shaw >Priority: Trivial > Labels: documentation > Attachments: book_HBASE_10459.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Broken link to first introduction to HBase video [0] > Second Introduction video works, so suspect a redirect at the other end is > broken or it's being changed in which case the second may stop working as > well. > Have supplied a patch > [0]https://hbase.apache.org/book.html#other.info.videos -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh reopened HBASE-10460:
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh updated HBASE-10460:
---
Affects Version/s: 0.98.0
Fix Version/s: 0.98.0
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void
[
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891338#comment-13891338
]
Jonathan Hsieh commented on HBASE-10460:
I think this should be in 0.98. Here are my two best reasons:
* This patch is a "simple best effort fix" (as [~lhofhansl] mentioned) and the
current implementation seems to be a going out of the way to break things. I
don't see how it this one is an API cleanup (in Java convention, setters return
void) and is seems to be a gratuitous compat breaking change that is easy low
risk fix.
* This method is in a class marked InterfaceAudience.Public and
InterfaceStability.Stable. [1] If this were marked
InterfaceStability.Evolving I'd be ok with the "won't do" resolution but
because it is Stable we should keep this around. and allow this patch in 0.98.
[1]
https://github.com/apache/hbase/blob/0.96/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java#L82
> Return value of Scan#setSmall() should be void
> --
>
> Key: HBASE-10460
> URL: https://issues.apache.org/jira/browse/HBASE-10460
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 10460.txt
>
>
> Aleksandr Shulman reported the following incompatibility between 0.96 and
> 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available
> for download' thread:
> {code}
> Exception from testScanMeta: -> java.lang.NoSuchMethodError:
> org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
> {code}
> Return value of Scan#setSmall() should be void
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891325#comment-13891325 ] Hudson commented on HBASE-10457: FAILURE: Integrated in HBase-0.94-JDK7 #38 (See [https://builds.apache.org/job/HBase-0.94-JDK7/38/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564429) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10452) Potential bugs in exception handlers
[
https://issues.apache.org/jira/browse/HBASE-10452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891326#comment-13891326
]
Hadoop QA commented on HBASE-10452:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12626957/HBase-10452-trunk-v2.patch
against trunk revision .
ATTACHMENT ID: 12626957
{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 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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/8595//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8595//console
This message is automatically generated.
> Potential bugs in exception handlers
>
>
> Key: HBASE-10452
> URL: https://issues.apache.org/jira/browse/HBASE-10452
> Project: HBase
> Issue Type: Bug
> Components: Client, master, regionserver, util
>Affects Versions: 0.96.1
>Reporter: Ding Yuan
> Attachments: HBase-10452-trunk-v2.patch, HBase-10452-trunk.patch
>
>
> Hi HBase developers,
> We are a group of researchers on software reliability. Recently we did a
> study and found that majority of the most severe failures in HBase are caused
> by bugs in exception handling logic -- that it is hard to anticipate all the
> possible real-world error scenarios. Therefore we built a simple checking
> tool that automatically detects some bug patterns that have caused some very
> severe real-world failures. I am reporting some of the results here. Any
> feedback is much appreciated!
> Ding
> =
> Case 1:
> Line: 134, File:
> "org/apache/hadoop/hbase/regionserver/RegionMergeRequest.java"
> {noformat}
> protected void releaseTableLock() {
> if (this.tableLock != null) {
> try {
> this.tableLock.release();
> } catch (IOException ex) {
> LOG.warn("Could not release the table lock", ex);
> //TODO: if we get here, and not abort RS, this lock will never be
> released
> }
> }
> {noformat}
> The lock is not released if the exception occurs, causing potential deadlock
> or starvation.
> Similar code pattern can be found at:
> Line: 135, File: "org/apache/hadoop/hbase/regionserver/SplitRequest.java"
> =
[jira] [Commented] (HBASE-10389) Add namespace help info in table related shell commands
[
https://issues.apache.org/jira/browse/HBASE-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891313#comment-13891313
]
Jonathan Hsieh commented on HBASE-10389:
many spots: are we allowed to regex the namespace part of the tablename also or
is it only the table part.?
{code}
diff --git a/hbase-shell/src/main/ruby/shell/commands/disable_all.rb
b/hbase-shell/src/main/ruby/shell/commands/disable_all.rb
index 0e7c30e..1793a42 100644
--- a/hbase-shell/src/main/ruby/shell/commands/disable_all.rb
+++ b/hbase-shell/src/main/ruby/shell/commands/disable_all.rb
@@ -25,6 +25,8 @@ module Shell
Disable all of tables matching the given regex:
hbase> disable_all 't.*'
+hbase> disable_all 'ns:t.*'
+hbase> disable_all 'ns:.*'
EOF
{code}
> Add namespace help info in table related shell commands
> ---
>
> Key: HBASE-10389
> URL: https://issues.apache.org/jira/browse/HBASE-10389
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0, 0.96.1
>Reporter: Jerry He
>Assignee: Jerry He
> Attachments: HBASE-10389-trunk.patch
>
>
> Currently in the help info of table related shell command, we don't mention
> or give namespace as part of the table name.
> For example, to create table:
> {code}
> hbase(main):001:0> help 'create'
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily
> including NAME attribute.
> Examples:
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}
> hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
> hbase> # The above in shorthand would be the following:
> hbase> create 't1', 'f1', 'f2', 'f3'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000,
> BLOCKCACHE => true}
> hbase> create 't1', {NAME => 'f1', CONFIGURATION =>
> {'hbase.hstore.blockingStoreFiles' => '10'}}
> Table configuration options can be put at the end.
> Examples:
> hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
> hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' =>
> 'myvalue' }
> hbase> # Optionally pre-split the table into NUMREGIONS, using
> hbase> # SPLITALGO ("HexStringSplit", "UniformSplit" or classname)
> hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
> hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit',
> CONFIGURATION => {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}}
> You can also keep around a reference to the created table:
> hbase> t1 = create 't1', 'f1'
> Which gives you a reference to the table named 't1', on which you can then
> call methods.
> {code}
> We should document the usage of namespace in these commands.
> For example:
> #namespace=foo and table qualifier=bar
> create 'foo:bar', 'fam'
> #namespace=default and table qualifier=bar
> create 'bar', 'fam'
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
[ https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-10465: Status: Patch Available (was: Open) > TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes > --- > > Key: HBASE-10465 > URL: https://issues.apache.org/jira/browse/HBASE-10465 > Project: HBase > Issue Type: Test >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Trivial > Attachments: hbase-10465.patch > > > It looks like sleeping 100 ms is not enough for the permission change to > propagate to other watchers. Will increase the sleeping time a little. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
[ https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-10465: Attachment: hbase-10465.patch > TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes > --- > > Key: HBASE-10465 > URL: https://issues.apache.org/jira/browse/HBASE-10465 > Project: HBase > Issue Type: Test >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Trivial > Attachments: hbase-10465.patch > > > It looks like sleeping 100 ms is not enough for the permission change to > propagate to other watchers. Will increase the sleeping time a little. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10466) Wrong calculation of total memstore size in HRegion which could cause data loss
Yunfan Zhong created HBASE-10466: Summary: Wrong calculation of total memstore size in HRegion which could cause data loss Key: HBASE-10466 URL: https://issues.apache.org/jira/browse/HBASE-10466 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.89-fb Reporter: Yunfan Zhong Priority: Critical Fix For: 0.89-fb When there are failed flushes, data to be flush are kept in each MemStore's snapshot. Next flush attempt will continue on snapshot first. However, the counter of total memstore size in HRegion is always deduced by the sum of current memstore sizes after the flush succeeds. This calculation is definitely wrong if flush fails last time. When the server is shutting down, there are two flushes. During the missing KV issue period, the first flush successfully saved data in snapshot. But the size counter was reduced to 0 or even less. This prevented the second flush since HRegion.internalFlushcache() directly returns while total memstore size is not greater than 0. As result, data in memstores were lost. It could cause mass data loss up to the size limit of each memstore. For example, a region had 516.3M data (size limit is 516M) in memstore at the moment because of failing flushes for more than one hour. After the region was closed, these KVs were missing from HFiles but exist in HLog. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891283#comment-13891283 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in hbase-0.96 #280 (See [https://builds.apache.org/job/hbase-0.96/280/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564428) * /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Moved] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
[ https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang moved HDFS-5883 to HBASE-10465: --- Key: HBASE-10465 (was: HDFS-5883) Project: HBase (was: Hadoop HDFS) > TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes > --- > > Key: HBASE-10465 > URL: https://issues.apache.org/jira/browse/HBASE-10465 > Project: HBase > Issue Type: Test >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang >Priority: Trivial > > It looks like sleeping 100 ms is not enough for the permission change to > propagate to other watchers. Will increase the sleeping time a little. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10389) Add namespace help info in table related shell commands
[
https://issues.apache.org/jira/browse/HBASE-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891279#comment-13891279
]
Hadoop QA commented on HBASE-10389:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12626937/HBASE-10389-trunk.patch
against trunk revision .
ATTACHMENT ID: 12626937
{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 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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/8594//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8594//console
This message is automatically generated.
> Add namespace help info in table related shell commands
> ---
>
> Key: HBASE-10389
> URL: https://issues.apache.org/jira/browse/HBASE-10389
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.96.0, 0.96.1
>Reporter: Jerry He
>Assignee: Jerry He
> Attachments: HBASE-10389-trunk.patch
>
>
> Currently in the help info of table related shell command, we don't mention
> or give namespace as part of the table name.
> For example, to create table:
> {code}
> hbase(main):001:0> help 'create'
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily
> including NAME attribute.
> Examples:
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}
> hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
> hbase> # The above in shorthand would be the following:
> hbase> create 't1', 'f1', 'f2', 'f3'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000,
> BLOCKCACHE => true}
> hbase> create 't1', {NAME => 'f1', CONFIGURATION =>
> {'hbase.hstore.blockingStoreFiles' => '10'}}
> Table configuration options can be put at the end.
> Examples:
> hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
> hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
> hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' =>
> '
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891277#comment-13891277 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in HBase-0.94 #1272 (See [https://builds.apache.org/job/HBase-0.94/1272/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564429) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10464) Race condition during RS shutdown that could cause data loss
[ https://issues.apache.org/jira/browse/HBASE-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunfan Zhong updated HBASE-10464: - Resolution: Fixed Status: Resolved (was: Patch Available) > Race condition during RS shutdown that could cause data loss > > > Key: HBASE-10464 > URL: https://issues.apache.org/jira/browse/HBASE-10464 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.89-fb >Reporter: Yunfan Zhong >Priority: Critical > Fix For: 0.89-fb > > Attachments: D1120497.diff > > > Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): > 1. Master assigns a region to RS at T1 > 2. RS works on opening the region during T1 to T3 > 3. In the mean time of opening the region, RS starts to shut down at T2, and > dfs client is closed at T5. > 4. Regions owned by the RS get closed as a step of RS shutdown except that > the newly opened region is online during T3 to T5 and holds some mutations in > memory after possible last flush T4. > 5. Since master thinks RS has a clean shutdown, there is no log splitting. > The HLog was moved to old logs directory naturally. > 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are > not flushed. They only exist in WAL if it is turned on. > Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10464) Race condition during RS shutdown that could cause data loss
[ https://issues.apache.org/jira/browse/HBASE-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunfan Zhong updated HBASE-10464: - Status: Patch Available (was: Open) > Race condition during RS shutdown that could cause data loss > > > Key: HBASE-10464 > URL: https://issues.apache.org/jira/browse/HBASE-10464 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.89-fb >Reporter: Yunfan Zhong >Priority: Critical > Fix For: 0.89-fb > > Attachments: D1120497.diff > > > Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): > 1. Master assigns a region to RS at T1 > 2. RS works on opening the region during T1 to T3 > 3. In the mean time of opening the region, RS starts to shut down at T2, and > dfs client is closed at T5. > 4. Regions owned by the RS get closed as a step of RS shutdown except that > the newly opened region is online during T3 to T5 and holds some mutations in > memory after possible last flush T4. > 5. Since master thinks RS has a clean shutdown, there is no log splitting. > The HLog was moved to old logs directory naturally. > 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are > not flushed. They only exist in WAL if it is turned on. > Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10464) Race condition during RS shutdown that could cause data loss
[ https://issues.apache.org/jira/browse/HBASE-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunfan Zhong updated HBASE-10464: - Attachment: D1120497.diff > Race condition during RS shutdown that could cause data loss > > > Key: HBASE-10464 > URL: https://issues.apache.org/jira/browse/HBASE-10464 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.89-fb >Reporter: Yunfan Zhong >Priority: Critical > Fix For: 0.89-fb > > Attachments: D1120497.diff > > > Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): > 1. Master assigns a region to RS at T1 > 2. RS works on opening the region during T1 to T3 > 3. In the mean time of opening the region, RS starts to shut down at T2, and > dfs client is closed at T5. > 4. Regions owned by the RS get closed as a step of RS shutdown except that > the newly opened region is online during T3 to T5 and holds some mutations in > memory after possible last flush T4. > 5. Since master thinks RS has a clean shutdown, there is no log splitting. > The HLog was moved to old logs directory naturally. > 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are > not flushed. They only exist in WAL if it is turned on. > Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10464) Race condition during RS shutdown that could cause data loss
[ https://issues.apache.org/jira/browse/HBASE-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunfan Zhong updated HBASE-10464: - Status: Open (was: Patch Available) > Race condition during RS shutdown that could cause data loss > > > Key: HBASE-10464 > URL: https://issues.apache.org/jira/browse/HBASE-10464 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.89-fb >Reporter: Yunfan Zhong >Priority: Critical > Fix For: 0.89-fb > > > Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): > 1. Master assigns a region to RS at T1 > 2. RS works on opening the region during T1 to T3 > 3. In the mean time of opening the region, RS starts to shut down at T2, and > dfs client is closed at T5. > 4. Regions owned by the RS get closed as a step of RS shutdown except that > the newly opened region is online during T3 to T5 and holds some mutations in > memory after possible last flush T4. > 5. Since master thinks RS has a clean shutdown, there is no log splitting. > The HLog was moved to old logs directory naturally. > 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are > not flushed. They only exist in WAL if it is turned on. > Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10464) Race condition during RS shutdown that could cause data loss
[ https://issues.apache.org/jira/browse/HBASE-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunfan Zhong updated HBASE-10464: - Status: Patch Available (was: Open) > Race condition during RS shutdown that could cause data loss > > > Key: HBASE-10464 > URL: https://issues.apache.org/jira/browse/HBASE-10464 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.89-fb >Reporter: Yunfan Zhong >Priority: Critical > Fix For: 0.89-fb > > > Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): > 1. Master assigns a region to RS at T1 > 2. RS works on opening the region during T1 to T3 > 3. In the mean time of opening the region, RS starts to shut down at T2, and > dfs client is closed at T5. > 4. Regions owned by the RS get closed as a step of RS shutdown except that > the newly opened region is online during T3 to T5 and holds some mutations in > memory after possible last flush T4. > 5. Since master thinks RS has a clean shutdown, there is no log splitting. > The HLog was moved to old logs directory naturally. > 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are > not flushed. They only exist in WAL if it is turned on. > Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (HBASE-10464) Race condition during RS shutdown that could cause data loss
Yunfan Zhong created HBASE-10464: Summary: Race condition during RS shutdown that could cause data loss Key: HBASE-10464 URL: https://issues.apache.org/jira/browse/HBASE-10464 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 0.89-fb Reporter: Yunfan Zhong Priority: Critical Fix For: 0.89-fb Bug scenario (T* are timestamps, say T1 < T2 < ... < Tn): 1. Master assigns a region to RS at T1 2. RS works on opening the region during T1 to T3 3. In the mean time of opening the region, RS starts to shut down at T2, and dfs client is closed at T5. 4. Regions owned by the RS get closed as a step of RS shutdown except that the newly opened region is online during T3 to T5 and holds some mutations in memory after possible last flush T4. 5. Since master thinks RS has a clean shutdown, there is no log splitting. The HLog was moved to old logs directory naturally. 6. Mutations in memory between T4 to T5 (if T4 does not exist, T3 to T5) are not flushed. They only exist in WAL if it is turned on. Fix is to prevent region opening from succeeding when the RS is shutting down. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891259#comment-13891259 ] Hudson commented on HBASE-10457: SUCCESS: Integrated in HBase-0.94-security #399 (See [https://builds.apache.org/job/HBase-0.94-security/399/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564429) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10454) Tags presence file info can be wrong in HFiles when PrefixTree encoding is used
[ https://issues.apache.org/jira/browse/HBASE-10454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891211#comment-13891211 ] Hudson commented on HBASE-10454: SUCCESS: Integrated in HBase-TRUNK #4882 (See [https://builds.apache.org/job/HBase-TRUNK/4882/]) HBASE-10454 Tags presence file info can be wrong in HFiles when PrefixTree encoding is used. (anoopsamjohn: rev 1564384) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileWriterV3.java > Tags presence file info can be wrong in HFiles when PrefixTree encoding is > used > --- > > Key: HBASE-10454 > URL: https://issues.apache.org/jira/browse/HBASE-10454 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10454.patch, HBASE-10454_V2.patch > > > We always encode tags in case of Prefix tree now and so the code path, while > decoding, not checking what is there in FileInfo. So functionally no issues > now. > If we do HBASE-10453 this change will be very important to make sure BC for > old files. > We use the file info MAX_TAGS_LEN to know the presence of tags in a file. In > case of prefix tree we always have tags in files even if all kvs have 0 tags. > So better we can add this file info into prefix tree encoded HFiles. Now it > get missed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (HBASE-10457) Print corrupted file information in SnapshotInfo tool without -file option
[ https://issues.apache.org/jira/browse/HBASE-10457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13891194#comment-13891194 ] Hudson commented on HBASE-10457: FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #9 (See [https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/9/]) HBASE-10457 Print corrupted file information in SnapshotInfo tool without -file option (Bharath Vissapragada) (mbertozzi: rev 1564429) * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/snapshot/SnapshotInfo.java > Print corrupted file information in SnapshotInfo tool without -file option > -- > > Key: HBASE-10457 > URL: https://issues.apache.org/jira/browse/HBASE-10457 > Project: HBase > Issue Type: Improvement > Components: snapshots >Affects Versions: 0.99.0 >Reporter: bharath v >Assignee: bharath v >Priority: Minor > Fix For: 0.98.0, 0.96.2, 0.94.18 > > Attachments: HBASE-10457-trunk-v0.patch, HBASE-10457-trunk-v1.patch > > > Currently SnapshotInfo tool prints the corrupted snapshot information only if > the user provides -file options. This might mislead the user sometimes. This > patch prints the corrupt files information even without the -file option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (HBASE-10337) HTable.get() uninteruptible
[ https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Liochon updated HBASE-10337: Status: Patch Available (was: Open) > HTable.get() uninteruptible > --- > > Key: HBASE-10337 > URL: https://issues.apache.org/jira/browse/HBASE-10337 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.96.1.1, 0.94.9, 0.98.0, 0.99.0 >Reporter: Jonathan Leech >Assignee: Nicolas Liochon > Fix For: 0.98.0, 0.99.0 > > Attachments: 10337.v1.patch, 10337.v2.patch > > > I've got a stuck thread on HTable.get() that can't be interrupted, looks like > its designed to be interruptible but can't be in interrupted in practice due > to while loop. > The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line > 981, it catches InterruptedException then goes right back to waiting due to > the while loop. > It looks like future versions of the client (.95+) are significantly > different and might not have this problem... Not sure about release schedules > etc. or if this version is still getting patched. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
