[jira] [Updated] (HBASE-11231) Modify test-patch.sh to use git repository
[ https://issues.apache.org/jira/browse/HBASE-11231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-11231: --- Component/s: build > Modify test-patch.sh to use git repository > -- > > Key: HBASE-11231 > URL: https://issues.apache.org/jira/browse/HBASE-11231 > Project: HBase > Issue Type: Test > Components: build >Reporter: Ted Yu > Attachments: hbase-11231-test.patch > > > HBase source code is being migrated to git repo. > test-patch.sh should be modified to accommodate this transition. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11131) Improve essential column family handling when more than one SingleColumnValueFilter is involved
[
https://issues.apache.org/jira/browse/HBASE-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-11131:
---
Component/s: Filters
> Improve essential column family handling when more than one
> SingleColumnValueFilter is involved
> ---
>
> Key: HBASE-11131
> URL: https://issues.apache.org/jira/browse/HBASE-11131
> Project: HBase
> Issue Type: Task
> Components: Filters
>Reporter: Ted Yu
>Priority: Minor
>
> Currently, SingleColumnValueFilter determines essential column family based
> on:
> {code}
> public boolean isFamilyEssential(byte[] name) {
> return !this.filterIfMissing || Bytes.equals(name, this.columnFamily);
> {code}
> When more than one SingleColumnValueFilter is used through FilterList, some
> optimization can be done.
> e.g. when they are chained by Operator.MUST_PASS_ALL, the second and
> subsequent SingleColumnValueFilter can declare to be non-essential.
> This way their evaluation would depend on the outcome of the first
> SingleColumnValueFilter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (HBASE-11105) Add bandwidth limit documentation to snapshot export section of refguide
[ https://issues.apache.org/jira/browse/HBASE-11105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu resolved HBASE-11105. Resolution: Implemented > Add bandwidth limit documentation to snapshot export section of refguide > > > Key: HBASE-11105 > URL: https://issues.apache.org/jira/browse/HBASE-11105 > Project: HBase > Issue Type: Task >Reporter: Ted Yu >Assignee: Gustavo Anatoly >Priority: Minor > > http://hbase.apache.org/book.html#ops.snapshots.export lists command line > arguments for ExportSnapshot > Parameters for bandwidth limitation (HBASE-11083) should be documented. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11107) Provide utility method equivalent to 0.92's Result.getBytes().getSize()
[
https://issues.apache.org/jira/browse/HBASE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020851#comment-14020851
]
Gustavo Anatoly commented on HBASE-11107:
-
Hi, [~rekhajoshm].
I will assign this task for me :)
Thanks.
> Provide utility method equivalent to 0.92's Result.getBytes().getSize()
> ---
>
> Key: HBASE-11107
> URL: https://issues.apache.org/jira/browse/HBASE-11107
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Assignee: Rekha Joshi
>Priority: Trivial
>
> Currently user has to write code similar to the following for replacement of
> Result.getBytes().getSize() :
> {code}
> +Cell[] cellValues = resultRow.rawCells();
> +
> +long size = 0L;
> +if (null != cellValues) {
> + for (Cell cellValue : cellValues) {
> +size += KeyValueUtil.ensureKeyValue(cellValue).heapSize();
> + }
> +}
> {code}
> In ClientScanner, we have:
> {code}
> for (Cell kv : rs.rawCells()) {
> // TODO make method in Cell or CellUtil
> remainingResultSize -=
> KeyValueUtil.ensureKeyValue(kv).heapSize();
> }
> {code}
> A utility method should be provided which computes summation of Cell sizes in
> a Result.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (HBASE-11107) Provide utility method equivalent to 0.92's Result.getBytes().getSize()
[
https://issues.apache.org/jira/browse/HBASE-11107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gustavo Anatoly reassigned HBASE-11107:
---
Assignee: Gustavo Anatoly (was: Rekha Joshi)
> Provide utility method equivalent to 0.92's Result.getBytes().getSize()
> ---
>
> Key: HBASE-11107
> URL: https://issues.apache.org/jira/browse/HBASE-11107
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Assignee: Gustavo Anatoly
>Priority: Trivial
>
> Currently user has to write code similar to the following for replacement of
> Result.getBytes().getSize() :
> {code}
> +Cell[] cellValues = resultRow.rawCells();
> +
> +long size = 0L;
> +if (null != cellValues) {
> + for (Cell cellValue : cellValues) {
> +size += KeyValueUtil.ensureKeyValue(cellValue).heapSize();
> + }
> +}
> {code}
> In ClientScanner, we have:
> {code}
> for (Cell kv : rs.rawCells()) {
> // TODO make method in Cell or CellUtil
> remainingResultSize -=
> KeyValueUtil.ensureKeyValue(kv).heapSize();
> }
> {code}
> A utility method should be provided which computes summation of Cell sizes in
> a Result.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11052) Sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/HBASE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-11052: -- Attachment: HBASE-11052_trunk_v4.patch > Sending random data crashes thrift service > -- > > Key: HBASE-11052 > URL: https://issues.apache.org/jira/browse/HBASE-11052 > Project: HBase > Issue Type: Bug > Components: Thrift >Affects Versions: 0.98.1, 1.0.0, 0.94.18 >Reporter: Adrian Muraru > Fix For: 1.0.0, 0.94.21, 0.98.4 > > Attachments: HBASE-11052_0.94_v2.patch, HBASE-11052_0.94_v4.patch, > HBASE-11052_trunk_v1.patch, HBASE-11052_trunk_v3.patch, > HBASE-11052_trunk_v4.patch > > > Upstream thrift library has a know issue (THRIFT-601) causing the thrift > server to crash with an Out-of-Memory Error when bogus requests are sent. > This reproduces when a very large request size is sent in the request header, > making the thrift server to allocate a large memory segment leading to OOM. > LoadBalancer health checks are the first "candidate" for bogus requests > Thrift developers admit this is a known issue with TBinaryProtocol and their > recommandation is to use TCompactProtocol/TFramedTransport but this requires > all thrift clients to be updated (might not be feasible atm) > So we need a fix similar to CASSANDRA-475. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11052) Sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/HBASE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020900#comment-14020900 ] Adrian Muraru commented on HBASE-11052: --- patch ver4 for trunk - reverting defaults in hbase-default.xml as they were making tests fail > Sending random data crashes thrift service > -- > > Key: HBASE-11052 > URL: https://issues.apache.org/jira/browse/HBASE-11052 > Project: HBase > Issue Type: Bug > Components: Thrift >Affects Versions: 0.98.1, 1.0.0, 0.94.18 >Reporter: Adrian Muraru > Fix For: 1.0.0, 0.94.21, 0.98.4 > > Attachments: HBASE-11052_0.94_v2.patch, HBASE-11052_0.94_v4.patch, > HBASE-11052_trunk_v1.patch, HBASE-11052_trunk_v3.patch, > HBASE-11052_trunk_v4.patch > > > Upstream thrift library has a know issue (THRIFT-601) causing the thrift > server to crash with an Out-of-Memory Error when bogus requests are sent. > This reproduces when a very large request size is sent in the request header, > making the thrift server to allocate a large memory segment leading to OOM. > LoadBalancer health checks are the first "candidate" for bogus requests > Thrift developers admit this is a known issue with TBinaryProtocol and their > recommandation is to use TCompactProtocol/TFramedTransport but this requires > all thrift clients to be updated (might not be feasible atm) > So we need a fix similar to CASSANDRA-475. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11052) Sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/HBASE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Muraru updated HBASE-11052: -- Release Note: Thrift servers should use framed/compact protocol to protect against buffer overflow (default disabled as they are breaking old clients) - hbase.regionserver.thrift.framed = true - hbase.regionserver.thrift.compact = true was: Thrift servers are now using framed/compact protocol to protect against buffer overflow: - hbase.regionserver.thrift.framed = true - hbase.regionserver.thrift.compact = true > Sending random data crashes thrift service > -- > > Key: HBASE-11052 > URL: https://issues.apache.org/jira/browse/HBASE-11052 > Project: HBase > Issue Type: Bug > Components: Thrift >Affects Versions: 0.98.1, 1.0.0, 0.94.18 >Reporter: Adrian Muraru > Fix For: 1.0.0, 0.94.21, 0.98.4 > > Attachments: HBASE-11052_0.94_v2.patch, HBASE-11052_0.94_v4.patch, > HBASE-11052_trunk_v1.patch, HBASE-11052_trunk_v3.patch, > HBASE-11052_trunk_v4.patch > > > Upstream thrift library has a know issue (THRIFT-601) causing the thrift > server to crash with an Out-of-Memory Error when bogus requests are sent. > This reproduces when a very large request size is sent in the request header, > making the thrift server to allocate a large memory segment leading to OOM. > LoadBalancer health checks are the first "candidate" for bogus requests > Thrift developers admit this is a known issue with TBinaryProtocol and their > recommandation is to use TCompactProtocol/TFramedTransport but this requires > all thrift clients to be updated (might not be feasible atm) > So we need a fix similar to CASSANDRA-475. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[ https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-11304: - Attachment: HBASE-11304-trunk-v1.patch > Enable HBaseAdmin.execProcedure to return data from procedure execution > --- > > Key: HBASE-11304 > URL: https://issues.apache.org/jira/browse/HBASE-11304 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch > > > HBASE-11201 enables global procedure members to return data to procedure > master. > HBASE-9426 lets user invoke procedure from client via > HBaseAdmin.execProcedure. > This JIRA is to fill the gap to enable client to get return data from master > after procedure execution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[ https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020946#comment-14020946 ] Jerry He commented on HBASE-11304: -- Attached v1 to address [~mbertozzi] and [~tedyu]'s comments. > Enable HBaseAdmin.execProcedure to return data from procedure execution > --- > > Key: HBASE-11304 > URL: https://issues.apache.org/jira/browse/HBASE-11304 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch > > > HBASE-11201 enables global procedure members to return data to procedure > master. > HBASE-9426 lets user invoke procedure from client via > HBaseAdmin.execProcedure. > This JIRA is to fill the gap to enable client to get return data from master > after procedure execution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11052) Sending random data crashes thrift service
[
https://issues.apache.org/jira/browse/HBASE-11052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020949#comment-14020949
]
Hadoop QA commented on HBASE-11052:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12648824/HBASE-11052_trunk_v4.patch
against trunk revision .
ATTACHMENT ID: 12648824
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 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/9717//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9717//console
This message is automatically generated.
> Sending random data crashes thrift service
> --
>
> Key: HBASE-11052
> URL: https://issues.apache.org/jira/browse/HBASE-11052
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Affects Versions: 0.98.1, 1.0.0, 0.94.18
>Reporter: Adrian Muraru
> Fix For: 1.0.0, 0.94.21, 0.98.4
>
> Attachments: HBASE-11052_0.94_v2.patch, HBASE-11052_0.94_v4.patch,
> HBASE-11052_trunk_v1.patch, HBASE-11052_trunk_v3.patch,
> HBASE-11052_trunk_v4.patch
>
>
> Upstream thrift library has a know issue (THRIFT-601) causing the thrift
> server to crash with an Out-of-Memory Error when bogus requests are sent.
> This reproduces when a very large request size is sent in the request header,
> making the thrift server to allocate a large memory segment leading to OOM.
> LoadBalancer health checks are the first "candidate" for bogus requests
> Thrift developers admit this is a known issue with TBinaryProtocol and their
> recommandation is to use TCompactProtocol/TFramedTransport but this requires
> all thrift clients to be updated (might not be feasible atm)
> So we need a fix similar to CASSANDRA-475.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
Ted Yu created HBASE-11308:
--
Summary: Reuse NameStringPair#Builder instances in loops
Key: HBASE-11308
URL: https://issues.apache.org/jira/browse/HBASE-11308
Project: HBase
Issue Type: Task
Reporter: Ted Yu
Priority: Minor
The following code is from HColumnDescriptor#convert() but the pattern can be
found in other classes, such as HBaseAdmin:
{code}
for (Map.Entry e : this.configuration.entrySet()) {
NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
aBuilder.setName(e.getKey());
aBuilder.setValue(e.getValue());
builder.addConfiguration(aBuilder.build());
}
{code}
NameStringPair.Builder instance can be reused across iterations of the loop.
This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[
https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020958#comment-14020958
]
Ted Yu commented on HBASE-11304:
Looks good overall.
In MasterProcedureManager.java:
{code}
- public abstract void execProcedure(ProcedureDescription desc) throws
IOException;
+ public void execProcedure(ProcedureDescription desc) throws IOException {
{code}
What was the intention for the above change ?
> Enable HBaseAdmin.execProcedure to return data from procedure execution
> ---
>
> Key: HBASE-11304
> URL: https://issues.apache.org/jira/browse/HBASE-11304
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 0.99.0
>
> Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch
>
>
> HBASE-11201 enables global procedure members to return data to procedure
> master.
> HBASE-9426 lets user invoke procedure from client via
> HBaseAdmin.execProcedure.
> This JIRA is to fill the gap to enable client to get return data from master
> after procedure execution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-11059: Attachment: hbase-11059_v2.1.patch Attached patch v2.1 that passed unit test and itbll locally. For 1million empty regions on 39 nodes, openregion threads set to 20, with the patch it took about 5 minutes to assign them all. Without the patch, it took about 68 minutes. > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-11059: Fix Version/s: 0.99.0 Status: Patch Available (was: Open) > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.99.0 > > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[
https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020992#comment-14020992
]
Hadoop QA commented on HBASE-11304:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12648827/HBASE-11304-trunk-v1.patch
against trunk revision .
ATTACHMENT ID: 12648827
{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 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 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:
+ * rpc ExecProcedureWithRet(.ExecProcedureRequest) returns
(.ExecProcedureResponse);
+ * rpc ExecProcedureWithRet(.ExecProcedureRequest) returns
(.ExecProcedureResponse);
{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.mapreduce.TestImportExport.testMetaExport(TestImportExport.java:209)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9718//console
This message is automatically generated.
> Enable HBaseAdmin.execProcedure to return data from procedure execution
> ---
>
> Key: HBASE-11304
> URL: https://issues.apache.org/jira/browse/HBASE-11304
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Fix For: 0.99.0
>
> Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch
>
>
> HBASE-11201 enables global procedure members to return data to procedure
> master.
> HBASE-9426 lets user invoke procedure from client via
> HBaseAdmin.execProcedure.
> This JIRA is to fill the gap to enable client to get return data from master
> after procedure execution.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11059) ZK-less region assignment
[
https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021014#comment-14021014
]
Hadoop QA commented on HBASE-11059:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12648832/hbase-11059_v2.1.patch
against trunk revision .
ATTACHMENT ID: 12648832
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 60 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 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:
+ * rpc ReportRegionTransition(.ReportRegionTransitionRequest)
returns (.ReportRegionTransitionResponse);
+ * rpc ReportRegionTransition(.ReportRegionTransitionRequest)
returns (.ReportRegionTransitionResponse);
+ } else if (!useZKForAssignment ||
asyncSetOfflineInZooKeeper(state, cb, destination)) {
{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/9719//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9719//console
This message is automatically generated.
> ZK-less region assignment
> -
>
> Key: HBASE-11059
> URL: https://issues.apache.org/jira/browse/HBASE-11059
> Project: HBase
> Issue Type: Improvement
> Components: master, Region Assignment
>Reporter: Jimmy Xiang
>Assignee: Jimmy Xiang
> Fix For: 0.99.0
>
> Attachments: hbase-11059.patch, hbase-11059_v2.1.patch,
> hbase-11059_v2.patch, zk-less_am.pdf
>
>
> It seems that most people don't like region assignment with ZK (HBASE-5487),
> which causes many uncertainties. This jira is to support ZK-less region
> assignment. We need to make sure this patch doesn't break backward
> compatibility/rolling upgrade.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[ https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021043#comment-14021043 ] Jerry He commented on HBASE-11304: -- Hi, Ted Thanks for the review. bq. What was the intention for the above change ? Yes, I wanted to put empty implementations in MasterProcedureManager for both ExecProcedure() and ExecProcedureWithRet() so that a child class can choose to overide either of them. The long lines are from the generated/MasterProtos.java file. Is there a way to fix them? > Enable HBaseAdmin.execProcedure to return data from procedure execution > --- > > Key: HBASE-11304 > URL: https://issues.apache.org/jira/browse/HBASE-11304 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch > > > HBASE-11201 enables global procedure members to return data to procedure > master. > HBASE-9426 lets user invoke procedure from client via > HBaseAdmin.execProcedure. > This JIRA is to fill the gap to enable client to get return data from master > after procedure execution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11309) Remove USE_POSITION_BEFORE and related code from PrefixTreeSeeker
Ted Yu created HBASE-11309: -- Summary: Remove USE_POSITION_BEFORE and related code from PrefixTreeSeeker Key: HBASE-11309 URL: https://issues.apache.org/jira/browse/HBASE-11309 Project: HBase Issue Type: Task Reporter: Ted Yu Priority: Minor This constant is always false in PrefixTreeSeeker. We can remove this variable and the code depending on this boolean to be true. Thanks to Matt Corgan who confirmed the above. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[ https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021058#comment-14021058 ] Ted Yu commented on HBASE-11304: The long line came from generated code - long line detector should be enhanced to deal with this. Will wait for a day to see if Matteo has more comments. Thanks Jerry. > Enable HBaseAdmin.execProcedure to return data from procedure execution > --- > > Key: HBASE-11304 > URL: https://issues.apache.org/jira/browse/HBASE-11304 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch > > > HBASE-11201 enables global procedure members to return data to procedure > master. > HBASE-9426 lets user invoke procedure from client via > HBaseAdmin.execProcedure. > This JIRA is to fill the gap to enable client to get return data from master > after procedure execution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11304) Enable HBaseAdmin.execProcedure to return data from procedure execution
[ https://issues.apache.org/jira/browse/HBASE-11304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021062#comment-14021062 ] Ted Yu commented on HBASE-11304: I ran TestImportExport locally and didn't observe regression caused by the patch. TestImportExport isn't related to procedure. > Enable HBaseAdmin.execProcedure to return data from procedure execution > --- > > Key: HBASE-11304 > URL: https://issues.apache.org/jira/browse/HBASE-11304 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Jerry He >Assignee: Jerry He >Priority: Minor > Fix For: 0.99.0 > > Attachments: HBASE-11304-trunk-v0.patch, HBASE-11304-trunk-v1.patch > > > HBASE-11201 enables global procedure members to return data to procedure > master. > HBASE-9426 lets user invoke procedure from client via > HBaseAdmin.execProcedure. > This JIRA is to fill the gap to enable client to get return data from master > after procedure execution. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11308:
--
Priority: Trivial (was: Minor)
Marking trivial. Looks like code path that is not in critical path. No numbers
on benefit making this change.
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Trivial
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021066#comment-14021066 ] stack commented on HBASE-11059: --- [~jxiang] Is the patch up on rb? > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.99.0 > > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021069#comment-14021069 ] Jimmy Xiang commented on HBASE-11059: - Yes, it is on RB. > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.99.0 > > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11298) Simplification in RpcServer code
[ https://issues.apache.org/jira/browse/HBASE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021071#comment-14021071 ] stack commented on HBASE-11298: --- bq. ...on RpcServer, am I wrong or is maxIdleTime set to 2 seconds? My feeling is it's actually never used because we don't track the rpcCount correctly ? Yeah, looks like 2 seconds. How is it that we don't track rpcCount correctly? It is upped when we read a request and downed when we respond? > Simplification in RpcServer code > > > Key: HBASE-11298 > URL: https://issues.apache.org/jira/browse/HBASE-11298 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.99.0 >Reporter: Nicolas Liochon >Assignee: Nicolas Liochon > Fix For: 0.99.0 > > Attachments: 11298.v1.patch > > > No important changes here, but I'm doing some other changes on top of this > (typically HBASE-11297) > > Note that I've changed the logs, they now belong to the "real" class instead > of hijacking Hadoop. I suppose it was historical, but it was as well very > confusing. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11302) ReplicationSourceManager#sources is not thread safe
[
https://issues.apache.org/jira/browse/HBASE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11302:
--
Attachment: HBase-11302-0.99 (1).patch
Retry
> ReplicationSourceManager#sources is not thread safe
> ---
>
> Key: HBASE-11302
> URL: https://issues.apache.org/jira/browse/HBASE-11302
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.99.0, 0.98.2
>Reporter: Qianxi Zhang
>Assignee: Qianxi Zhang
> Fix For: 0.99.0
>
> Attachments: HBase-11302-0.99 (1).patch, HBase-11302-0.99.diff
>
>
> In ReplicationSourceManager, sources is used to record the peers. It could be
> removed in removePeer method, and read in preLogRoll method. it is not thread
> safe.
> ReplicationSourceManager#296
> {code}
> void preLogRoll(Path newLog) throws IOException {
> synchronized (this.hlogsById) {
> String name = newLog.getName();
> for (ReplicationSourceInterface source : this.sources) {
> try {
> this.replicationQueues.addLog(source.getPeerClusterZnode(), name);
> } catch (ReplicationException e) {
> throw new IOException("Cannot add log to replication queue with id="
> + source.getPeerClusterZnode() + ", filename=" + name, e);
> }
> }
> for (SortedSet hlogs : this.hlogsById.values()) {
> if (this.sources.isEmpty()) {
> // If there's no slaves, don't need to keep the old hlogs since
> // we only consider the last one when a new slave comes in
> hlogs.clear();
> }
> hlogs.add(name);
> }
> }
> this.latestPath = newLog;
> }
> {code}
> ReplicationSourceManager#392
> {code}
> public void removePeer(String id) {
> LOG.info("Closing the following queue " + id + ", currently have "
> + sources.size() + " and another "
> + oldsources.size() + " that were recovered");
> String terminateMessage = "Replication stream was removed by a user";
> ReplicationSourceInterface srcToRemove = null;
> List oldSourcesToDelete =
> new ArrayList();
> // First close all the recovered sources for this peer
> for (ReplicationSourceInterface src : oldsources) {
> if (id.equals(src.getPeerClusterId())) {
> oldSourcesToDelete.add(src);
> }
> }
> for (ReplicationSourceInterface src : oldSourcesToDelete) {
> src.terminate(terminateMessage);
> closeRecoveredQueue((src));
> }
> LOG.info("Number of deleted recovered sources for " + id + ": "
> + oldSourcesToDelete.size());
> // Now look for the one on this cluster
> for (ReplicationSourceInterface src : this.sources) {
> if (id.equals(src.getPeerClusterId())) {
> srcToRemove = src;
> break;
> }
> }
> if (srcToRemove == null) {
> LOG.error("The queue we wanted to close is missing " + id);
> return;
> }
> srcToRemove.terminate(terminateMessage);
> this.sources.remove(srcToRemove);
> deleteSource(id, true);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-6192) Document ACL matrix in the book
[ https://issues.apache.org/jira/browse/HBASE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021077#comment-14021077 ] stack commented on HBASE-6192: -- [~apurtell] If you bless it, i'll commit sir. > Document ACL matrix in the book > --- > > Key: HBASE-6192 > URL: https://issues.apache.org/jira/browse/HBASE-6192 > Project: HBase > Issue Type: Task > Components: documentation, security >Affects Versions: 0.94.1, 0.95.2 >Reporter: Enis Soztutar >Assignee: Misty Stanley-Jones > Labels: documentaion, security > Fix For: 0.99.0 > > Attachments: HBASE-6192-rebased.patch, HBASE-6192.patch, HBase > Security-ACL Matrix.pdf, HBase Security-ACL Matrix.pdf, HBase Security-ACL > Matrix.pdf, HBase Security-ACL Matrix.xls, HBase Security-ACL Matrix.xls, > HBase Security-ACL Matrix.xls > > > We have an excellent matrix at > https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf > for ACL. Once the changes are done, we can adapt that and put it in the > book, also add some more documentation about the new authorization features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-7394) Document security config requirements from HBASE-7357
[ https://issues.apache.org/jira/browse/HBASE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021078#comment-14021078 ] stack commented on HBASE-7394: -- [~mbertozzi] What you think of Misty's patch mighty matteo? > Document security config requirements from HBASE-7357 > - > > Key: HBASE-7394 > URL: https://issues.apache.org/jira/browse/HBASE-7394 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Gary Helmling >Assignee: Misty Stanley-Jones > Attachments: HBASE-7394-rebased.patch, HBASE-7394.patch > > > Running secure HBase has always effectively required setting both > hbase.security.authentication and hadoop.security.authentication, but > internal usage was inconsistent. HBASE-7357 cleaned up the internal code > usage. We should update the ref guide security docs to explicitly call out > the requirement the hadoop.security.authentication be set as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11120) Update documentation about major compaction algorithm
[
https://issues.apache.org/jira/browse/HBASE-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021081#comment-14021081
]
stack commented on HBASE-11120:
---
Why did the patch go from 21k to 6k [~misty]? Did you get less ambitious?
Looking the below:
{code}
hbase.hstore.compaction.min.size
A StoreFile smaller than this size (in bytes) will
always be eligible for
minor compaction.
-10
+128 MB
hbase.hstore.compaction.max.size
A StoreFile larger than this size (in bytes) will
be excluded from minor
compaction.
-1000
+Long.MAX_VALUE
{code}
... I don't see hbase.hstore.compaction.min.size in code base any more and you
can't write Long.MAX_VALUE or 128 MB as values... our configuration system
can't digest anything but numbers.
Let me know why big difference in size. Maybe this patch should have had more
in it? Thanks.
> Update documentation about major compaction algorithm
> -
>
> Key: HBASE-11120
> URL: https://issues.apache.org/jira/browse/HBASE-11120
> Project: HBase
> Issue Type: Bug
> Components: Compaction, documentation
>Affects Versions: 0.98.2
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Attachments: HBASE-11120-2.patch, HBASE-11120-3-rebased.patch,
> HBASE-11120-3.patch, HBASE-11120-4-rebased.patch, HBASE-11120-4.patch,
> HBASE-11120.patch
>
>
> [14:20:38] seems that there's
> http://hbase.apache.org/book.html#compaction and
> http://hbase.apache.org/book.html#managed.compactions
> [14:20:56] the latter doesn't say much, except that you
> should manage them
> [14:21:44] the former gives a good description of the
> _old_ selection algo
> [14:45:25] this is the new selection algo since C5 /
> 0.96.0: https://issues.apache.org/jira/browse/HBASE-7842
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11285) Expand coprocs info in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021082#comment-14021082 ] stack commented on HBASE-11285: --- I skimmed this. It looks great [~misty] Before I commit, what was the source for this doc? Thanks boss. > Expand coprocs info in Ref Guide > > > Key: HBASE-11285 > URL: https://issues.apache.org/jira/browse/HBASE-11285 > Project: HBase > Issue Type: Bug > Components: Coprocessors, documentation >Affects Versions: 0.98.3 >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11285.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021069#comment-14021069 ] Jimmy Xiang edited comment on HBASE-11059 at 6/8/14 3:54 AM: - Yes, it is on RB: https://reviews.apache.org/r/21934/, the 3rd update. was (Author: jxiang): Yes, it is on RB. > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.99.0 > > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-11308:
---
Priority: Minor (was: Trivial)
I am not convinced that the priority of this JIRA should be lower than that of
HBASE-11305
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Minor
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11308:
--
Priority: Trivial (was: Minor)
Agree. That issue should have been marked trivial too.
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Trivial
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11305) Remove bunch of unused imports in HConnectionManager
[ https://issues.apache.org/jira/browse/HBASE-11305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11305: -- Priority: Trivial (was: Minor) > Remove bunch of unused imports in HConnectionManager > > > Key: HBASE-11305 > URL: https://issues.apache.org/jira/browse/HBASE-11305 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.99.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov >Priority: Trivial > Fix For: 0.99.0 > > Attachments: HBASE-11305.patch > > > remove unused imports. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021088#comment-14021088
]
Ted Yu commented on HBASE-11308:
Creating NameStringPair#Builder instances within loop occurs in
ProtobufUtil#toProtoNamespaceDescriptor() which is called by the following
methods:
ZKNamespaceManager#writeNamespace()
TableNamespaceManager#upsert()
MasterRpcServices#listNamespaceDescriptors()
The above methods are frequently called.
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Trivial
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-11308:
---
Priority: Minor (was: Trivial)
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Minor
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11059) ZK-less region assignment
[ https://issues.apache.org/jira/browse/HBASE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021103#comment-14021103 ] stack commented on HBASE-11059: --- ok. I went over RB and left some comments. Minor for the most part. Did not review actual transitions too closely figuring that unit tests and IT will find issues before I would. I'm +1 for committing this. Would be cool to get a +1 from a [~jeffreyz] too... or at least a skim by Jeffrey (Jeffrey, this is sweet work!). +1 would be to commit with this feature off. We'd then file an issue against 1.0 to turn it on by default. In that issue we'd make the case for why this should be on. Suggest you pull out the comments for rolling restart and shove them in as the release note for this JIRA. Good on you Jimmy. > ZK-less region assignment > - > > Key: HBASE-11059 > URL: https://issues.apache.org/jira/browse/HBASE-11059 > Project: HBase > Issue Type: Improvement > Components: master, Region Assignment >Reporter: Jimmy Xiang >Assignee: Jimmy Xiang > Fix For: 0.99.0 > > Attachments: hbase-11059.patch, hbase-11059_v2.1.patch, > hbase-11059_v2.patch, zk-less_am.pdf > > > It seems that most people don't like region assignment with ZK (HBASE-5487), > which causes many uncertainties. This jira is to support ZK-less region > assignment. We need to make sure this patch doesn't break backward > compatibility/rolling upgrade. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11308) Reuse NameStringPair#Builder instances in loops
[
https://issues.apache.org/jira/browse/HBASE-11308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-11308:
--
Priority: Trivial (was: Minor)
Definetly not in the critical path Suggest you go make code changes that
will make an actual difference perf or otherwise.
> Reuse NameStringPair#Builder instances in loops
> ---
>
> Key: HBASE-11308
> URL: https://issues.apache.org/jira/browse/HBASE-11308
> Project: HBase
> Issue Type: Task
>Reporter: Ted Yu
>Priority: Trivial
>
> The following code is from HColumnDescriptor#convert() but the pattern can be
> found in other classes, such as HBaseAdmin:
> {code}
> for (Map.Entry e : this.configuration.entrySet()) {
> NameStringPair.Builder aBuilder = NameStringPair.newBuilder();
> aBuilder.setName(e.getKey());
> aBuilder.setValue(e.getValue());
> builder.addConfiguration(aBuilder.build());
> }
> {code}
> NameStringPair.Builder instance can be reused across iterations of the loop.
> This would save creation of short-lived objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-7394) Document security config requirements from HBASE-7357
[ https://issues.apache.org/jira/browse/HBASE-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021119#comment-14021119 ] Matteo Bertozzi commented on HBASE-7394: +1 looks ok to me > Document security config requirements from HBASE-7357 > - > > Key: HBASE-7394 > URL: https://issues.apache.org/jira/browse/HBASE-7394 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Gary Helmling >Assignee: Misty Stanley-Jones > Attachments: HBASE-7394-rebased.patch, HBASE-7394.patch > > > Running secure HBase has always effectively required setting both > hbase.security.authentication and hadoop.security.authentication, but > internal usage was inconsistent. HBASE-7357 cleaned up the internal code > usage. We should update the ref guide security docs to explicitly call out > the requirement the hadoop.security.authentication be set as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11295) Long running scan produces OutOfOrderScannerNextException
[ https://issues.apache.org/jira/browse/HBASE-11295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14021126#comment-14021126 ] Anoop Sam John commented on HBASE-11295: U can see in ClientScanner that we will treat outof order exception. We are not throwing back to app layer immediately. We will recreate a scanner with start row as the last previous fetched row. But again this also throws same exception with out fetching any thing we will stop and throw back to app. Else we will end in this way of infinite retries. ( pls note that the retries with same scannerid is finite no# ) In ur case this might be happening. U sleep in filter. If u are having such a long running scenario ( one next call will take more time may be becuase of complex filtering or so ) try reducing scanner caching ( default is 100) and/or increasing client time out. I dont think there is any problem in code. The log says the retry from client on out of order exception. > Long running scan produces OutOfOrderScannerNextException > - > > Key: HBASE-11295 > URL: https://issues.apache.org/jira/browse/HBASE-11295 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.96.0 >Reporter: Jeff Cunningham > Attachments: OutOfOrderScannerNextException.tar.gz > > > Attached Files: > HRegionServer.java - instramented from 0.96.1.1-cdh5.0.0 > HBaseLeaseTimeoutIT.java - reproducing JUnit 4 test > WaitFilter.java - Scan filter (extends FilterBase) that overrides > filterRowKey() to sleep during invocation > SpliceFilter.proto - Protobuf defintiion for WaitFilter.java > OutOfOrderScann_InstramentedServer.log - instramented server log > Steps.txt - this note > Set up: > In HBaseLeaseTimeoutIT, create a scan, set the given filter (which sleeps in > overridden filterRowKey() method) and set it on the scan, and scan the table. > This is done in test client_0x0_server_15x10(). > Here's what I'm seeing (see also attached log): > A new request comes into server (ID 1940798815214593802 - > RpcServer.handler=96) and a RegionScanner is created for it, cached by ID, > immediately looked up again and cached RegionScannerHolder's nextCallSeq > incremeted (now at 1). > The RegionScan thread goes to sleep in WaitFilter#filterRowKey(). > A short (variable) period later, another request comes into the server (ID > 8946109289649235722 - RpcServer.handler=98) and the same series of events > happen to this request. > At this point both RegionScanner threads are sleeping in > WaitFilter.filterRowKey(). After another period, the client retries another > scan request which thinks its next_call_seq is 0. However, HRegionServer's > cached RegionScannerHolder thinks the matching RegionScanner's nextCallSeq > should be 1. -- This message was sent by Atlassian JIRA (v6.2#6252)
