[jira] [Commented] (HBASE-17407) Correct update of maxFlushedSeqId in HRegion
[
https://issues.apache.org/jira/browse/HBASE-17407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831348#comment-15831348
]
Duo Zhang commented on HBASE-17407:
---
Let's just remove the old startCacheFlush method? The WAL interface is marked
as @InterfaceAudience.Private.
And mind explaining this change?
{quote}
if (flushing != null) {
for (Map.Entry e : flushing.entrySet()) {
Long currentId = tmpMap.get(e.getKey());
-if (currentId != null && currentId.longValue() <=
e.getValue().longValue()) {
+if (currentId != null && currentId.longValue() <
e.getValue().longValue()) {
{quote}
Why changing '<=' to '<' ?
Thanks.
> Correct update of maxFlushedSeqId in HRegion
>
>
> Key: HBASE-17407
> URL: https://issues.apache.org/jira/browse/HBASE-17407
> Project: HBase
> Issue Type: Bug
>Reporter: Eshcar Hillel
> Attachments: HBASE-17407-V01.patch, HBASE-17407-V01.patch,
> HBASE-17407-V02.patch
>
>
> The attribute maxFlushedSeqId in HRegion is used to track the max sequence id
> in the store files and is reported to HMaster. When flushing only part of the
> memstore content this value might be incorrect and may cause data loss.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-17500) Implement getTable/creatTable/deleteTable/truncateTable methods
Guanghao Zhang created HBASE-17500: -- Summary: Implement getTable/creatTable/deleteTable/truncateTable methods Key: HBASE-17500 URL: https://issues.apache.org/jira/browse/HBASE-17500 Project: HBase Issue Type: Sub-task Reporter: Guanghao Zhang Assignee: Guanghao Zhang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17346) Add coprocessor service support
[
https://issues.apache.org/jira/browse/HBASE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15829428#comment-15829428
]
Duo Zhang edited comment on HBASE-17346 at 1/20/17 7:29 AM:
The stubMaker and callable are just bridges to the generated protobuf code. A
stubMaker is usually a {{XXXService.newStub(RpcChannel)}} method call, and the
callable is usually a {{stub.xxx(RpcController, Message, RpcCallback)}} call.
All the parameters will be prepared by us and user just need to pass them to
the right method.
Yes it exposes some internals to user so that's why I just keep them in the
RawAsyncTable interface. It should only be used by advanced users.
{quote}
The channel and controller we get from where? Ditto 'done' I don't see them in
the aggregation class.
{quote}
See the RegionCoprocessorRpcChannelImpl class.
And for the callback, onRegionComplete is used to tell you that there is a
result for a particular region, and onComplete is used to tell you that the
operation is finished, i.e., there is no new onRegionComplete. This is because
the region locator itself is also asynchronous, and I want to send actual
request to region on the fly, i.e., send a request immediately after we get the
location of a region without getting all the regions and their locations. So we
need to find a way to tell user that there is no new region, that's why we have
an onComplete method.
And the onError method is called when locating error. Typically onRegionError
and onError have the same effect that you should fail the whole operation as we
have already retried many times.
{quote}
You don't need PayloadCarryingRpcController here, right
{quote}
PCRC extends the shaded RpcController, we can not use it for coprocessor call...
Thanks.
was (Author: apache9):
The stubMaker and callable are just bridges to the generated protobuf code. A
stubMaker is usually a {{XXXService.newStub(RpcChannel)}} method call, and the
callable is usually a {{stub.xxx(RpcController, Message, RpcCallback)}} call.
All the parameters will be prepared by us and user just need to pass them to
the right method.
Yes it exposes some internals to user so that's why I just keep them in the
RawAsyncTable interface. It should only be used by advanced users.
{quote}
The channel and controller we get from where? Ditto 'done' I don't see them in
the aggregation class.
{quote}
See the RegionCoprocessorRpcChannelImpl class.
And for the callback, onRegionComplete is used to tell you that there is a
result for a particular region, and onComplete is used to tell you that the
operation is finished, i.e., there is no new onRegionComplete. This is because
the region locator itself is also asynchronous, and I want to send actual
request to region on the fly, i.e., send a request immediately after we get the
location of a region without getting all the region and their locations. So we
need to find a way to tell user that there is no region, that's why we have an
onComplete method.
And the onError method is called when locating error. Typically onRegionError
and onError have the same effect that you should fail the whole operation as we
have already retried many times.
{quote}
You don't need PayloadCarryingRpcController here, right
{quote}
PCRC extends the shaded RpcController, we can not use it for coprocessor call...
Thanks.
> Add coprocessor service support
> ---
>
> Key: HBASE-17346
> URL: https://issues.apache.org/jira/browse/HBASE-17346
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, Coprocessors
>Affects Versions: 2.0.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: 17346.suggestion.txt, HBASE-17346.patch,
> HBASE-17346-v1.patch
>
>
> I think we need to redesign the API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted
[ https://issues.apache.org/jira/browse/HBASE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831337#comment-15831337 ] Duo Zhang commented on HBASE-17489: --- [~stack] [~enis] PTAL. Thanks. > ClientScanner may send a next request to a RegionScanner which has been > exhausted > - > > Key: HBASE-17489 > URL: https://issues.apache.org/jira/browse/HBASE-17489 > Project: HBase > Issue Type: Bug > Components: Client, scan >Affects Versions: 2.0.0, 1.3.0, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.1 > > Attachments: HBASE-17489.patch, HBASE-17489-v1.patch, > HBASE-17489-v2.patch, HBASE-17489-v3.patch > > > Found it when implementing HBASE-17045. Seems the final result of the scan is > correct but no doubt the logic is broken. We need to fix it to stop things > get worse in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted
[ https://issues.apache.org/jira/browse/HBASE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17489: -- Attachment: HBASE-17489-v3.patch Close scanner at RS side automatically when no more results. This is part of the patch in HBASE-17045 but I think we can apply it to all branches so integrate it here. > ClientScanner may send a next request to a RegionScanner which has been > exhausted > - > > Key: HBASE-17489 > URL: https://issues.apache.org/jira/browse/HBASE-17489 > Project: HBase > Issue Type: Bug > Components: Client, scan >Affects Versions: 2.0.0, 1.3.0, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.1 > > Attachments: HBASE-17489.patch, HBASE-17489-v1.patch, > HBASE-17489-v2.patch, HBASE-17489-v3.patch > > > Found it when implementing HBASE-17045. Seems the final result of the scan is > correct but no doubt the logic is broken. We need to fix it to stop things > get worse in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17489) ClientScanner may send a next request to a RegionScanner which has been exhausted
[ https://issues.apache.org/jira/browse/HBASE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17489: -- Affects Version/s: 1.4.0 1.3.0 Fix Version/s: 1.3.1 1.4.0 > ClientScanner may send a next request to a RegionScanner which has been > exhausted > - > > Key: HBASE-17489 > URL: https://issues.apache.org/jira/browse/HBASE-17489 > Project: HBase > Issue Type: Bug > Components: Client, scan >Affects Versions: 2.0.0, 1.3.0, 1.4.0 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Critical > Fix For: 2.0.0, 1.4.0, 1.3.1 > > Attachments: HBASE-17489.patch, HBASE-17489-v1.patch, > HBASE-17489-v2.patch, HBASE-17489-v3.patch > > > Found it when implementing HBASE-17045. Seems the final result of the scan is > correct but no doubt the logic is broken. We need to fix it to stop things > get worse in the future. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13652) Case-insensitivity of file system affects table creation
[
https://issues.apache.org/jira/browse/HBASE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831321#comment-15831321
]
Xuesen Liang commented on HBASE-13652:
--
ping [~esteban]
> Case-insensitivity of file system affects table creation
>
>
> Key: HBASE-13652
> URL: https://issues.apache.org/jira/browse/HBASE-13652
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.0.0
> Environment: HBase standalone mode on Mac OS X.
>Reporter: Lars George
>Assignee: Xuesen Liang
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-13652.master.001.patch,
> HBASE-13652.master.002.patch, HBASE-13652.master.003.patch,
> HBASE-13652.master.004.patch, HBASE-13652.master.005.patch
>
>
> I noticed this on my Mac OS machine:
> {noformat}
> hbase(main):003:0> list
> TABLE
>
>
> 0 row(s) in 0.0260 seconds
> => []
> hbase(main):004:0> create 'TestTable', 'info'
> 0 row(s) in 0.2830 seconds
> => Hbase::Table - TestTable
> hbase(main):005:0> create 'testtable', 'colfam1'
> 0 row(s) in 0.1750 seconds
> => Hbase::Table - testtable
> hbase(main):006:0> list
> TABLE
>
>
> TestTable
>
>
> TestTable
>
>
> 2 row(s) in 0.0170 seconds
> => ["TestTable", "TestTable"]
> hbase(main):007:0> status 'detailed'
> version 1.0.0
> 0 regionsInTransition
> master coprocessors: []
> 1 live servers
> de1-app-mba-1.internal.larsgeorge.com:58824 1431124680152
> requestsPerSecond=0.0, numberOfOnlineRegions=4, usedHeapMB=47,
> maxHeapMB=4062, numberOfStores=4, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=16, writeRequestsCount=8,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> coprocessors=[]
> "TestTable,,1431124762491.cb30b003b192aa1d429e5a8e908a2f7d."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:meta,,1"
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=10, writeRequestsCount=6,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:namespace,,1431124686536.42728f3a3411b0d8ff21c7a2622d9378."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "testtable,,1431124773352.8d461d5069d1c88bc3b26562ab30e333."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> 0 dead servers
> {noformat}
> and on the file system there is
> {noformat}
> larsgeorge:~$ ls -l hbase/data/default/
> total 0
> drwxr-xr-x 7 larsgeorge staff 238 May 8 15:39 TestTable
> {noformat}
> This should not happen on a case sensitive file system (I presume), so is of
> marginal importance. But a simple extra check during directory creation could
> fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17491) Remove all setters from HTable interface and introduce a TableBuilder to build Table instance
[
https://issues.apache.org/jira/browse/HBASE-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831307#comment-15831307
]
stack commented on HBASE-17491:
---
Remove this on commit:
2856// trivial change to trigger UT TODO remove me
2857LOG.trace("HRegionServer#main");
This is probably small potatoes in the scheme of things but you pass a
TableBuilderImpl to the HTable constructor rather than the Interface. Is this
because the implementation has the table name? The builder shouldn't have the
tablename in it because it is required field? I suppose having the talbename in
the builder makes it so you can set different op timeouts dependent on if it a
system table or not
How do I get a TableBuilder?
Thanks [~carp84]
> Remove all setters from HTable interface and introduce a TableBuilder to
> build Table instance
> -
>
> Key: HBASE-17491
> URL: https://issues.apache.org/jira/browse/HBASE-17491
> Project: HBase
> Issue Type: Sub-task
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17491.patch, HBASE-17491.v2.patch,
> HBASE-17491.v3.patch
>
>
> As titled, we will remove all setters in HTable for master branch and
> deprecate them for branch-1 to make HTable thread-safe. And a new
> {{TableBuilder}} interface will be introduced to build Table instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17487) Throw exception when pushing pipeline to snapshot fails twice
[ https://issues.apache.org/jira/browse/HBASE-17487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831304#comment-15831304 ] Anoop Sam John commented on HBASE-17487: When this exception is thrown up, what will happen to the original snapshot call? May be we should throw an Exception which will not make issues up.. It is handled up layer? > Throw exception when pushing pipeline to snapshot fails twice > - > > Key: HBASE-17487 > URL: https://issues.apache.org/jira/browse/HBASE-17487 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Minor > Attachments: 17487.v2.txt > > > In CompactingMemStore#pushPipelineToSnapshot() , there is limit of 3 > iterations of pipeline.swap() call after which an empty ImmutableSegment is > used as snapshot. > However, there should be at most two iterations in pushPipelineToSnapshot() > since during the second iteration there is no concurrent write to memstore. > We should throw exception in the 3rd iteration to signify that this scenario > should never happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17491) Remove all setters from HTable interface and introduce a TableBuilder to build Table instance
[
https://issues.apache.org/jira/browse/HBASE-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831286#comment-15831286
]
Duo Zhang commented on HBASE-17491:
---
LGTM. +1.
> Remove all setters from HTable interface and introduce a TableBuilder to
> build Table instance
> -
>
> Key: HBASE-17491
> URL: https://issues.apache.org/jira/browse/HBASE-17491
> Project: HBase
> Issue Type: Sub-task
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17491.patch, HBASE-17491.v2.patch,
> HBASE-17491.v3.patch
>
>
> As titled, we will remove all setters in HTable for master branch and
> deprecate them for branch-1 to make HTable thread-safe. And a new
> {{TableBuilder}} interface will be introduced to build Table instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17498: -- Attachment: HBASE-17498-v1.patch Failures look unrelated. Retry. > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17498-v1.patch, HBASE-17498-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831281#comment-15831281 ] stack commented on HBASE-17067: --- -004 address some self-review findings. > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch, HBASE-17067.master.003.patch, > HBASE-17067.master.004.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17067: -- Attachment: HBASE-17067.master.004.patch > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch, HBASE-17067.master.003.patch, > HBASE-17067.master.004.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17494) Guard against cloning family of all cells if no data need be replicated
[
https://issues.apache.org/jira/browse/HBASE-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831270#comment-15831270
]
Hudson commented on HBASE-17494:
FAILURE: Integrated in Jenkins build HBase-1.4 #596 (See
[https://builds.apache.org/job/HBase-1.4/596/])
HBASE-17494 Guard against cloning family of all cells if no data need be
(tedyu: rev abc8c5edd3035216526b76a9000595fb19d90a6e)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/Replication.java
> Guard against cloning family of all cells if no data need be replicated
> ---
>
> Key: HBASE-17494
> URL: https://issues.apache.org/jira/browse/HBASE-17494
> Project: HBase
> Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 1.4.0
>
> Attachments: HBASE-17494.branch-1.v0.patch
>
>
> The replication is enabled by default, so we try to clone the family of all
> cells even if there is no replication at all.
> {noformat}
> family = CellUtil.cloneFamily(cell);
> // Unexpected, has a tendency to happen in unit tests
> assert htd.getFamily(family) != null;
> if (!scopes.containsKey(family)) {
> int scope = htd.getFamily(family).getScope();
> if (scope != REPLICATION_SCOPE_LOCAL) {
> scopes.put(family, scope);
> }
> }
> {noformat}
> HBASE-15205 had resolved this issue, but it is committed to master only.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17498) Implement listTables and listTableNames methods
[
https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831265#comment-15831265
]
Hadoop QA commented on HBASE-17498:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 30s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 36s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 45s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 33s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
43m 6s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 24s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 105m 55s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 178m 25s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestMobSnapshotCloneIndependence |
| Timed out junit tests |
org.apache.hadoop.hbase.regionserver.TestCorruptedRegionStoreFile |
| | org.apache.hadoop.hbase.coprocessor.TestWALObserver |
| | org.apache.hadoop.hbase.regionserver.TestSplitWalDataLoss |
| | org.apache.hadoop.hbase.TestMetaTableAccessor |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848448/HBASE-17498-v1.patch |
| JIRA Issue | HBASE-17498 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux ee6ccda2a909 3.13.0-92-generic #139-Ubuntu SMP Tue Jun 28
20:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 4fdd6ff |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit |
[jira] [Commented] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831257#comment-15831257 ] stack commented on HBASE-17067: --- -003 addresses javadoc, whitespace, and failing tests. Looking for a review @appy or [~syuanjiang] Thanks. > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch, HBASE-17067.master.003.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17067: -- Attachment: HBASE-17067.master.003.patch > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch, HBASE-17067.master.003.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831214#comment-15831214
]
Guangxu Cheng edited comment on HBASE-17496 at 1/20/17 5:36 AM:
After merge the patch as follows:
{code}
hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
default
1 row(s)
Took 0.3950 seconds
{code}
{code}
hbase(main):002:0> list_rsgroups
GROUPS
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):003:0> get_table_rsgroup 't1'
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):004:0> get_rsgroup 'default'
GROUP INFORMATION
Servers:
hbase-01:16030
Tables:
hbase:meta
t1
hbase:namespace
hbase:rsgroup
7 row(s)
Took 0.0130 seconds
{code}
was (Author: andrewcheng):
After merge the patch as follows:
{code}
hbase(main):001:0> get_server_rsgroup '10.57.22.78:60020'
default
1 row(s)
Took 0.3950 seconds
{code}
{code}
hbase(main):002:0> list_rsgroups
GROUPS
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):003:0> get_table_rsgroup 't1'
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):004:0> get_rsgroup 'default'
GROUP INFORMATION
Servers:
10.57.22.78:60020
Tables:
hbase:meta
t1
hbase:namespace
hbase:rsgroup
7 row(s)
Took 0.0130 seconds
{code}
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831219#comment-15831219
]
Guangxu Cheng commented on HBASE-17496:
---
[~stack] Example of the patch has been pasted in the previous message.Thanks
for your reviewing.
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17497) Add first async MetaTableAccessor impl and Implement tableExists method
[
https://issues.apache.org/jira/browse/HBASE-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831213#comment-15831213
]
Hadoop QA commented on HBASE-17497:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 54s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 56s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
1s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
29m 31s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 1s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 91m 11s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 142m 52s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848445/HBASE-17497-v1.patch |
| JIRA Issue | HBASE-17497 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 136c2c7c2d51 3.13.0-98-generic #145-Ubuntu SMP Sat Oct 8
20:13:07 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 4fdd6ff |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/5355/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/5355/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Add first async MetaTableAccessor impl and Implement
[jira] [Commented] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831214#comment-15831214
]
Guangxu Cheng commented on HBASE-17496:
---
After merge the patch as follows:
{code}
hbase(main):001:0> get_server_rsgroup '10.57.22.78:60020'
default
1 row(s)
Took 0.3950 seconds
{code}
{code}
hbase(main):002:0> list_rsgroups
GROUPS
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):003:0> get_table_rsgroup 't1'
default
1 row(s)
Took 0.0130 seconds
{code}
{code}
hbase(main):004:0> get_rsgroup 'default'
GROUP INFORMATION
Servers:
10.57.22.78:60020
Tables:
hbase:meta
t1
hbase:namespace
hbase:rsgroup
7 row(s)
Took 0.0130 seconds
{code}
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831193#comment-15831193
]
stack commented on HBASE-17496:
---
Can you paste examples of the patch working please [~andrewcheng] so I can
commit it?
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17497) Add first async MetaTableAccessor impl and Implement tableExists method
[ https://issues.apache.org/jira/browse/HBASE-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831190#comment-15831190 ] stack commented on HBASE-17497: --- +1 > Add first async MetaTableAccessor impl and Implement tableExists method > --- > > Key: HBASE-17497 > URL: https://issues.apache.org/jira/browse/HBASE-17497 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17497-v1.patch > > > HBaseAdmin use many MetaTableAccessor's static methods. So add a async > MetaTableAccessor for AsyncHBaseAdmin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16773) AccessController should access local region if possible
[
https://issues.apache.org/jira/browse/HBASE-16773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831184#comment-15831184
]
Hudson commented on HBASE-16773:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK7 #85 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/85/])
HBASE-16773 AccessController should access local region if possible (tedyu: rev
342169cc223c0055750168f7872b8707b67ff5cc)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
> AccessController should access local region if possible
> ---
>
> Key: HBASE-16773
> URL: https://issues.apache.org/jira/browse/HBASE-16773
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: 16773.branch-1.txt, 16773.v2.txt, 16773.v3.txt,
> 16773.v4.txt, 16773.v5.txt, 16773.v6.txt, 16773.v7.txt
>
>
> We observed the following in the stack trace of region server on a 1.1.2
> cluster:
> {code}
> "PriorityRpcServer.handler=19,queue=1,port=60200" #225 daemon prio=5
> os_prio=0 tid=0x7fb562296000 nid=0x81c0 runnable [0x7fb509a27000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x0003d4dfd770> (a sun.nio.ch.Util$2)
> - locked <0x0003d4dfd760> (a java.util.Collections$UnmodifiableSet)
> - locked <0x0003d4dfd648> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at
> org.apache.hadoop.net.SocketIOWithTimeout$SelectorPool.select(SocketIOWithTimeout.java:335)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:157)
> at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
> at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
> at java.io.FilterInputStream.read(FilterInputStream.java:133)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> - locked <0x0003d7dae180> (a java.io.BufferedInputStream)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.readStatus(HBaseSaslRpcClient.java:151)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:189)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:611)
> - locked <0x0003d5c7edc0> (a
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:156)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:737)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:734)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:734)
> - locked <0x0003d5c7edc0> (a
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:887)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:856)
> at org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1199)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.get(ClientProtos.java:32627)
> at org.apache.hadoop.hbase.client.HTable$3.call(HTable.java:854)
> at org.apache.hadoop.hbase.client.HTable$3.call(HTable.java:845)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:126)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:862)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:828)
> at
>
[jira] [Commented] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831176#comment-15831176
]
Hadoop QA commented on HBASE-17496:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 1s
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 1s
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} 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} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 8s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 34s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 33s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 37m 6s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848451/HBASE-17496-master-v1.patch
|
| JIRA Issue | HBASE-17496 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux c286b4771b20 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 4fdd6ff |
| Default Java | 1.8.0_111 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/5357/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/5357/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
>
[jira] [Commented] (HBASE-17278) [C++] Cell Scanner Implementation to be used by ResultScanner
[ https://issues.apache.org/jira/browse/HBASE-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831173#comment-15831173 ] Sudeep Sunthankar commented on HBASE-17278: --- Thanks for the feedback [~enis]. I referred to IOBUF tests in folly and read some documentation as well as tested by parsing cell_meta_block in response which as per your suggestion I obtained by setting the codec class to KeyValueCodec. Would also like to know your thoughts on methods such as Current(), CellBlockMetaLength() which are not overridden in the derived class. Should these also be defined as per the implementation ? > [C++] Cell Scanner Implementation to be used by ResultScanner > - > > Key: HBASE-17278 > URL: https://issues.apache.org/jira/browse/HBASE-17278 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Attachments: HBASE-17278.HBASE-14850.v1.patch, > HBASE-17278.HBASE-14850.v2.patch, HBASE-17278.HBASE-14850.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16867) Procedure V2 - Check ACLs for remote HBaseLock
[ https://issues.apache.org/jira/browse/HBASE-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831168#comment-15831168 ] Hudson commented on HBASE-16867: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2350 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2350/]) HBASE-16867 Procedure V2 - Check ACLs for MasterRpcServices' queueLock() (stack: rev 558a6bb9d71cde7fba240a8a454c32367f0ef4c0) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java > Procedure V2 - Check ACLs for remote HBaseLock > -- > > Key: HBASE-16867 > URL: https://issues.apache.org/jira/browse/HBASE-16867 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0 > > Attachments: HBASE-16867.master.001.patch, > HBASE-16867.master.002.patch, HBASE-16867.master.003.patch, > HBASE-16867.master.004.patch, HBASE-16867.master.005.patch > > > HBaseLock was added in HBASE-16744 to allow clients to take locks on > namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16831) Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock
[ https://issues.apache.org/jira/browse/HBASE-16831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831169#comment-15831169 ] Hudson commented on HBASE-16831: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2350 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2350/]) HBASE-16831 Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock (stack: rev 4fdd6ff9aef0979d7b4f07abe159dbe4c755ccff) * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/InterProcessLock.java * (edit) pom.xml * (edit) hbase-protocol-shaded/src/main/protobuf/ZooKeeper.proto * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/lock/ZKInterProcessWriteLock.java * (edit) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java * (edit) hbase-protocol/src/main/protobuf/ZooKeeper.proto * (edit) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/generated/ZooKeeperProtos.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/zookeeper/lock/TestZKInterProcessReadWriteLock.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/lock/ZKInterProcessLockBase.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/lock/ZKInterProcessReadWriteLock.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/lock/ZKInterProcessReadLock.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/InterProcessReadWriteLock.java > Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock > > > Key: HBASE-16831 > URL: https://issues.apache.org/jira/browse/HBASE-16831 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Appy >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16831.master.001.patch, > HBASE-16831.master.002.patch > > > HBASE-16786 removes all uses of zk locks. Can delete the zk lock > implementation now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[
https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831147#comment-15831147
]
Hadoop QA commented on HBASE-17067:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 11m 46s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 46s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 7s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 28s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
22s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 26s
{color} | {color:red} hbase-server generated 1 new + 1 unchanged - 0 fixed = 2
total (was 1) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 18s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 70m 47s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 127m 15s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.locking.TestLockProcedure |
| Timed out junit tests |
org.apache.hadoop.hbase.master.locking.TestLockManager |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.1 Server=1.12.1 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848430/HBASE-17067.master.002.patch
|
| JIRA Issue | HBASE-17067 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 383d396232e7 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13
00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 4fdd6ff |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/5352/artifact/patchprocess/whitespace-eol.txt
|
|
[jira] [Commented] (HBASE-14614) Procedure v2: Core Assignment Manager
[
https://issues.apache.org/jira/browse/HBASE-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831143#comment-15831143
]
Hadoop QA commented on HBASE-14614:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 64 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m 51s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 47s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
11s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 51s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 26s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 29s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 12s
{color} | {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 30s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 12s
{color} | {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 30s {color} |
{color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 12s {color} |
{color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 30s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 12s {color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 58 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 5s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 10s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 12s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 16s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.6.4. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 19s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.6.5. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 22s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 27s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.7.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 31s
{color} | {color:red} The patch causes 32 errors with Hadoop v2.7.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 33s
[jira] [Commented] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831128#comment-15831128 ] Guanghao Zhang commented on HBASE-17498: The API was copied from Admin interface. So I keep the options in AsyncAdmin interface too. PS: There are 5 listTables API and 5 listTableNames API in Admin interface... > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17498-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17278) [C++] Cell Scanner Implementation to be used by ResultScanner
[ https://issues.apache.org/jira/browse/HBASE-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831106#comment-15831106 ] Enis Soztutar commented on HBASE-17278: --- Thanks Sudeep. I like the use of the Cursors for reading from the IOBufs. Searched around the docs, but could not find a lot of examples. Did you see it anywhere, or you have read the code from folly? For the CellScanner, I think we would like to keep it as independent of the "cells being serialized in a buffer" concept. For example, Result object implements CellScanner in Java. In that terms, fields like beyond_block_data_ should go in the KeyValueCodec class instead. The KVCodec should be able to also encode bunch of cells to a given IOBuf. We will need that functionality when we are doing Puts, so we do not need that in this patch for now. However, lets still have a Decoder inside the KVCodec and have the Decoding logic be inside the Decoder. KVCoder.Decoder() will instantiate a decoder object. We'll add the Encoder later. > [C++] Cell Scanner Implementation to be used by ResultScanner > - > > Key: HBASE-17278 > URL: https://issues.apache.org/jira/browse/HBASE-17278 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Attachments: HBASE-17278.HBASE-14850.v1.patch, > HBASE-17278.HBASE-14850.v2.patch, HBASE-17278.HBASE-14850.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831102#comment-15831102 ] stack commented on HBASE-17498: --- Nice. Do you provide too many options in the API [~zghaobac]? Do we need being able to get HTD and names? We need to be able to filter on regex in the API? Just wondering. Otherwise, patch LGTM. > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17498-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831094#comment-15831094
]
stack commented on HBASE-17496:
---
Patch LGTM. See what hadoopqa says. Thanks [~andrewcheng]
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-17496:
--
Labels: rsgroup (was: )
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Tags: rsgroup
Status: Patch Available (was: Open)
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Labels: rsgroup
> Fix For: 2.0.0
>
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17485) [C++] Zookeeper quorum and znode lookup made configurable
[ https://issues.apache.org/jira/browse/HBASE-17485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831066#comment-15831066 ] Enis Soztutar commented on HBASE-17485: --- Thanks Sudeep for the patch. The patch does not apply, because I have committed HBASE-15705 which changes some of the related code. I think before this patch, we still need a nice way to create a config object and set parameters there rather than trying to write the same XML generation logic everywhere. Let me do a patch there before the next iteration for this patch. We also need to deal with zk quorum not having the client port in the string (which is usual in hbase configuration due to historical reasons). But we can do that after this patch. > [C++] Zookeeper quorum and znode lookup made configurable > - > > Key: HBASE-17485 > URL: https://issues.apache.org/jira/browse/HBASE-17485 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Attachments: HBASE-17485.HBASE-14850.v1.patch > > > Lookup for Zookeeper Quorum and Zookeeper Znode should be done using > Configuration instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
[
https://issues.apache.org/jira/browse/HBASE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guangxu Cheng updated HBASE-17496:
--
Attachment: HBASE-17496-master-v1.patch
> RSGroup shell commands:get_server_rsgroup don't work and commands display an
> incorrect result size
> --
>
> Key: HBASE-17496
> URL: https://issues.apache.org/jira/browse/HBASE-17496
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Attachments: HBASE-17496-master-v1.patch
>
>
> scenario as follows:
> {code}
> hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
> ERROR: undefined method `getRSGroupOfServer' for
> #
> Here is some help for this command:
> Get the group name the given region server is a member of.
> hbase> get_server_rsgroup 'server1:port1'
> Took 0.0160 seconds
> {code}
> {code}
> hbase(main):002:0> list_rsgroups
> GROUPS
> default
> 1484874115 row(s)
> Took 0.3830 seconds
> {code}
> {code}
> hbase(main):003:0> get_table_rsgroup 't1'
> default
> 1484874133 row(s)
> Took 0.0100 seconds
> {code}
> {code}
> hbase(main):004:0> get_rsgroup 'default'
> GROUP INFORMATION
> Servers:
> hbase-01:16030
> Tables:
> hbase:meta
> t1
> hbase:namespace
> hbase:rsgroup
> 1484874150 row(s)
> Took 0.0140 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831050#comment-15831050 ] Ted Yu commented on HBASE-17462: Logged HBASE-17499 for limiting total heap memory for RegionLoads. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Fix For: 2.0.0, 1.4.0 > > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17499) Bound the total heap memory used for the rolling average of RegionLoads
Ted Yu created HBASE-17499: -- Summary: Bound the total heap memory used for the rolling average of RegionLoads Key: HBASE-17499 URL: https://issues.apache.org/jira/browse/HBASE-17499 Project: HBase Issue Type: Improvement Reporter: Ted Yu Currently "hbase.master.balancer.stochastic.numRegionLoadsToRemember" controls the number of RegionLoads which are kept by StochasticLoadBalancer for each region. The parameter doesn't take into account the number of regions in the cluster. Meaning, the amount of heap consumed by RegionLoads would be out of norm for cluster with large number of regions. This issue is to see if we should bound the total heap memory used for the rolling average of RegionLoads. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17280) Add mechanism to control hbase cleaner behavior
[
https://issues.apache.org/jira/browse/HBASE-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831048#comment-15831048
]
Hadoop QA commented on HBASE-17280:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 45s
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 0s
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 0s
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 5m 24s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 16s
{color} | {color:green} branch-1.2 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 10s
{color} | {color:green} branch-1.2 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
19s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
33s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
26s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 21s
{color} | {color:green} branch-1.2 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 30s
{color} | {color:green} branch-1.2 passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 52s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 52s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 52s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 46s {color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
12s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 21s
{color} | {color:red} hbase-client-jdk1.8.0_111 with JDK v1.8.0_111 generated 2
new + 12 unchanged - 0 fixed = 14 total (was 12) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 27s
{color} | {color:red} hbase-client-jdk1.7.0_80 with JDK v1.7.0_80 generated 2
new + 12 unchanged - 0 fixed = 14 total (was 12) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 25s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 46s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} |
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-17462: --- Hadoop Flags: Reviewed Fix Version/s: 1.4.0 2.0.0 > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Fix For: 2.0.0, 1.4.0 > > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831045#comment-15831045
]
Ted Yu commented on HBASE-17462:
Patch looks good.
{code}
+ Double previous = null;
{code}
The boxing / unboxing of variable previous can be avoided by introducing a flag
which signals whether the current reading is the first one.
> Investigate using sliding window for read/write request costs in
> StochasticLoadBalancer
> ---
>
> Key: HBASE-17462
> URL: https://issues.apache.org/jira/browse/HBASE-17462
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Tim Brown
> Labels: patch
> Fix For: 2.0.0, 1.4.0
>
> Attachments: after_changes.png, before_changes.png, HBASE-17462.patch
>
>
> In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was
> asking whether the read/write request costs in StochasticLoadBalancer should
> be calculated as rates.
> This makes sense since read / write load on region server tends to fluctuate
> over time. Using sliding window would reflect more recent trend in read /
> write load.
> Some factors to consider:
> The data structure used by StochasticLoadBalancer should be concise. The
> number of regions in a cluster can be expected to approach 1 million. We
> cannot afford to store long history of read / write requests in master.
> Efficiency of cost calculation should be high - there're many cost
> functions the balancer goes through, it is expected for each cost function
> to return quickly. Otherwise we would not come up with proper region
> movement plan(s) in time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17498: --- Attachment: HBASE-17498-v1.patch > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17498-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17498: --- Status: Patch Available (was: Open) > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17498-v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831032#comment-15831032
]
Hadoop QA commented on HBASE-17462:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 12m 7s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 25s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 82m 30s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 128m 49s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848420/HBASE-17462.patch |
| JIRA Issue | HBASE-17462 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 5bfeeb65b7a8 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 76dc957 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/5351/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/5351/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Investigate using sliding window for read/write request costs in
> StochasticLoadBalancer
> ---
>
> Key: HBASE-17462
> URL: https://issues.apache.org/jira/browse/HBASE-17462
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Tim Brown
> Labels: patch
> Attachments: after_changes.png,
[jira] [Commented] (HBASE-14614) Procedure v2: Core Assignment Manager
[ https://issues.apache.org/jira/browse/HBASE-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831031#comment-15831031 ] stack commented on HBASE-14614: --- -007 is rebase atop new locking regime. Lets see how we do. > Procedure v2: Core Assignment Manager > - > > Key: HBASE-14614 > URL: https://issues.apache.org/jira/browse/HBASE-14614 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-14614.master.001.patch, > HBASE-14614.master.002.patch, HBASE-14614.master.003.patch, > HBASE-14614.master.004.patch, HBASE-14614.master.005.patch, > HBASE-14614.master.006.patch, HBASE-14614.master.007.patch > > > New AssignmentManager implemented using proc-v2. > - AssignProcedure handle assignment operation > - UnassignProcedure handle unassign operation > - MoveRegionProcedure handle move/balance operation > Concurrent Assign operations are batched together and sent to the balancer > Concurrent Assign and Unassign operation ready to be sent to the RS are > batched together > This patch is an intermediate state where we add the new AM as > AssignmentManager2() to the master, to be reached by tests. but the new AM > will not be integrated with the rest of the system. Only new am unit-tests > will exercise the new assigment manager. The integration with the master code > is part of HBASE-14616 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14614) Procedure v2: Core Assignment Manager
[ https://issues.apache.org/jira/browse/HBASE-14614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14614: -- Attachment: HBASE-14614.master.007.patch > Procedure v2: Core Assignment Manager > - > > Key: HBASE-14614 > URL: https://issues.apache.org/jira/browse/HBASE-14614 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-14614.master.001.patch, > HBASE-14614.master.002.patch, HBASE-14614.master.003.patch, > HBASE-14614.master.004.patch, HBASE-14614.master.005.patch, > HBASE-14614.master.006.patch, HBASE-14614.master.007.patch > > > New AssignmentManager implemented using proc-v2. > - AssignProcedure handle assignment operation > - UnassignProcedure handle unassign operation > - MoveRegionProcedure handle move/balance operation > Concurrent Assign operations are batched together and sent to the balancer > Concurrent Assign and Unassign operation ready to be sent to the RS are > batched together > This patch is an intermediate state where we add the new AM as > AssignmentManager2() to the master, to be reached by tests. but the new AM > will not be integrated with the rest of the system. Only new am unit-tests > will exercise the new assigment manager. The integration with the master code > is part of HBASE-14616 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17498) Implement listTables and listTableNames methods
[ https://issues.apache.org/jira/browse/HBASE-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17498: --- Summary: Implement listTables and listTableNames methods (was: Implement listTables methods) > Implement listTables and listTableNames methods > --- > > Key: HBASE-17498 > URL: https://issues.apache.org/jira/browse/HBASE-17498 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17498) Implement listTables methods
Guanghao Zhang created HBASE-17498: -- Summary: Implement listTables methods Key: HBASE-17498 URL: https://issues.apache.org/jira/browse/HBASE-17498 Project: HBase Issue Type: Sub-task Reporter: Guanghao Zhang Assignee: Guanghao Zhang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17497) Add first async MetaTableAccessor impl and Implement tableExists method
[ https://issues.apache.org/jira/browse/HBASE-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17497: --- Status: Patch Available (was: Open) > Add first async MetaTableAccessor impl and Implement tableExists method > --- > > Key: HBASE-17497 > URL: https://issues.apache.org/jira/browse/HBASE-17497 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17497-v1.patch > > > HBaseAdmin use many MetaTableAccessor's static methods. So add a async > MetaTableAccessor for AsyncHBaseAdmin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17497) Add first async MetaTableAccessor impl and Implement tableExists method
[ https://issues.apache.org/jira/browse/HBASE-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17497: --- Attachment: HBASE-17497-v1.patch > Add first async MetaTableAccessor impl and Implement tableExists method > --- > > Key: HBASE-17497 > URL: https://issues.apache.org/jira/browse/HBASE-17497 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17497-v1.patch > > > HBaseAdmin use many MetaTableAccessor's static methods. So add a async > MetaTableAccessor for AsyncHBaseAdmin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831013#comment-15831013 ] Ted Yu commented on HBASE-17462: Thinking about "hbase.master.balancer.stochastic.numRegionLoadsToRemember", the parameter doesn't take into account the number of regions in the cluster. Meaning, the amount of heap consumed by RegionLoads would be out of norm for cluster with large number of regions. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17497) Add first async MetaTableAccessor impl and Implement tableExists method
Guanghao Zhang created HBASE-17497: -- Summary: Add first async MetaTableAccessor impl and Implement tableExists method Key: HBASE-17497 URL: https://issues.apache.org/jira/browse/HBASE-17497 Project: HBase Issue Type: Sub-task Reporter: Guanghao Zhang Assignee: Guanghao Zhang HBaseAdmin use many MetaTableAccessor's static methods. So add a async MetaTableAccessor for AsyncHBaseAdmin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16773) AccessController should access local region if possible
[
https://issues.apache.org/jira/browse/HBASE-16773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831007#comment-15831007
]
Hudson commented on HBASE-16773:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK8 #98 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/98/])
HBASE-16773 AccessController should access local region if possible (tedyu: rev
342169cc223c0055750168f7872b8707b67ff5cc)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
> AccessController should access local region if possible
> ---
>
> Key: HBASE-16773
> URL: https://issues.apache.org/jira/browse/HBASE-16773
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: 16773.branch-1.txt, 16773.v2.txt, 16773.v3.txt,
> 16773.v4.txt, 16773.v5.txt, 16773.v6.txt, 16773.v7.txt
>
>
> We observed the following in the stack trace of region server on a 1.1.2
> cluster:
> {code}
> "PriorityRpcServer.handler=19,queue=1,port=60200" #225 daemon prio=5
> os_prio=0 tid=0x7fb562296000 nid=0x81c0 runnable [0x7fb509a27000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x0003d4dfd770> (a sun.nio.ch.Util$2)
> - locked <0x0003d4dfd760> (a java.util.Collections$UnmodifiableSet)
> - locked <0x0003d4dfd648> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at
> org.apache.hadoop.net.SocketIOWithTimeout$SelectorPool.select(SocketIOWithTimeout.java:335)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:157)
> at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:161)
> at org.apache.hadoop.net.SocketInputStream.read(SocketInputStream.java:131)
> at java.io.FilterInputStream.read(FilterInputStream.java:133)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> - locked <0x0003d7dae180> (a java.io.BufferedInputStream)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.readStatus(HBaseSaslRpcClient.java:151)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:189)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:611)
> - locked <0x0003d5c7edc0> (a
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$600(RpcClientImpl.java:156)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:737)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:734)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1724)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:734)
> - locked <0x0003d5c7edc0> (a
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:887)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:856)
> at org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1199)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:213)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:287)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.get(ClientProtos.java:32627)
> at org.apache.hadoop.hbase.client.HTable$3.call(HTable.java:854)
> at org.apache.hadoop.hbase.client.HTable$3.call(HTable.java:845)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:126)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:862)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:828)
> at
>
[jira] [Commented] (HBASE-17066) Procedure v2 - Add handling of merge region transition to the new AM
[ https://issues.apache.org/jira/browse/HBASE-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15831004#comment-15831004 ] stack commented on HBASE-17066: --- [~syuanjiang] What you think of this one? > Procedure v2 - Add handling of merge region transition to the new AM > > > Key: HBASE-17066 > URL: https://issues.apache.org/jira/browse/HBASE-17066 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Region Assignment >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > > Core Assignment HBASE-14614 does not handle merge in > reportRegionStateTransition(). Handle the transition request! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830988#comment-15830988 ] Tim Brown commented on HBASE-17462: --- Yes, different colors represent different regions. I tested this out on our staging environment which has variable amounts of activity. It's not due to the changes. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830977#comment-15830977 ] Ted Yu commented on HBASE-17462: Did different colors represent different regions ? How do you interpret the (lower) request counts readings after the change ? Thanks > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17496) RSGroup shell commands:get_server_rsgroup don't work and commands display an incorrect result size
Guangxu Cheng created HBASE-17496:
-
Summary: RSGroup shell commands:get_server_rsgroup don't work and
commands display an incorrect result size
Key: HBASE-17496
URL: https://issues.apache.org/jira/browse/HBASE-17496
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 2.0.0
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng
scenario as follows:
{code}
hbase(main):001:0> get_server_rsgroup 'hbase-01:16030'
ERROR: undefined method `getRSGroupOfServer' for
#
Here is some help for this command:
Get the group name the given region server is a member of.
hbase> get_server_rsgroup 'server1:port1'
Took 0.0160 seconds
{code}
{code}
hbase(main):002:0> list_rsgroups
GROUPS
default
1484874115 row(s)
Took 0.3830 seconds
{code}
{code}
hbase(main):003:0> get_table_rsgroup 't1'
default
1484874133 row(s)
Took 0.0100 seconds
{code}
{code}
hbase(main):004:0> get_rsgroup 'default'
GROUP INFORMATION
Servers:
hbase-01:16030
Tables:
hbase:meta
t1
hbase:namespace
hbase:rsgroup
1484874150 row(s)
Took 0.0140 seconds
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16942) FavoredNodes - Balancer improvements
[
https://issues.apache.org/jira/browse/HBASE-16942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830955#comment-15830955
]
Hadoop QA commented on HBASE-16942:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 7 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 49s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 49s
{color} | {color:red} hbase-server generated 2 new + 0 unchanged - 0 fixed = 2
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 85m 7s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 122m 47s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Exception is caught when Exception is not thrown in
org.apache.hadoop.hbase.master.balancer.FavoredStochasticBalancer.retainAssignment(Map,
List) At FavoredStochasticBalancer.java:is not thrown in
org.apache.hadoop.hbase.master.balancer.FavoredStochasticBalancer.retainAssignment(Map,
List) At FavoredStochasticBalancer.java:[line 358] |
| |
org.apache.hadoop.hbase.master.balancer.FavoredStochasticBalancer.retainAssignment(Map,
List) makes inefficient use of keySet iterator instead of entrySet iterator
At FavoredStochasticBalancer.java:of keySet iterator instead of entrySet
iterator At FavoredStochasticBalancer.java:[line 346] |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848410/HBASE-16942.master.002.patch
|
| JIRA Issue | HBASE-16942 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 68cd2def88b0 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 76dc957 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| findbugs |
[jira] [Commented] (HBASE-17443) Move listReplicated/enableTableRep/disableTableRep methods from ReplicationAdmin to Admin
[
https://issues.apache.org/jira/browse/HBASE-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830951#comment-15830951
]
Guanghao Zhang commented on HBASE-17443:
Yeah, now the new api return a table-cfs map and remove the custom keys.
{code}
* @return the replicated table-cfs map of this cluster as:
*
Map> listReplicatedTableCFs() throws IOException;
{code}
> Move listReplicated/enableTableRep/disableTableRep methods from
> ReplicationAdmin to Admin
> -
>
> Key: HBASE-17443
> URL: https://issues.apache.org/jira/browse/HBASE-17443
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17443-v1.patch, HBASE-17443-v2.patch,
> HBASE-17443-v2.patch, HBASE-17443-v3.patch, HBASE-17443-v3.patch,
> HBASE-17443-v4.patch, HBASE-17443-v5.patch
>
>
> We have moved other replication requests to Admin and mark ReplicationAdmin
> as Deprecated, so listReplicated/enableTableRep/disableTableRep methods need
> move to Admin, too.
> Review board: https://reviews.apache.org/r/55534/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12894) Upgrade Jetty to 9.2.6
[
https://issues.apache.org/jira/browse/HBASE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830948#comment-15830948
]
Guang Yang commented on HBASE-12894:
Thanks [~busbey]. For the findbugs issue being reported:
{noformat}
Possible doublecheck on
org.apache.hadoop.hbase.rest.model.ScannerModel.jsonProvider in
org.apache.hadoop.hbase.rest.model.ScannerModel.getJasonProvider()
{noformat}
It is done that way intentionally to use double checked locking to lazy
initialize the instance.
> Upgrade Jetty to 9.2.6
> --
>
> Key: HBASE-12894
> URL: https://issues.apache.org/jira/browse/HBASE-12894
> Project: HBase
> Issue Type: Improvement
> Components: REST, UI
>Affects Versions: 0.98.0
>Reporter: Rick Hallihan
>Assignee: Guang Yang
>Priority: Critical
> Labels: MicrosoftSupport
> Fix For: 2.0.0
>
> Attachments: dependency_list_after, dependency_list_before,
> HBASE-12894_Jetty9_v0.patch, HBASE-12894_Jetty9_v10.patch,
> HBASE-12894_Jetty9_v1.patch, HBASE-12894_Jetty9_v1.patch,
> HBASE-12894_Jetty9_v2.patch, HBASE-12894_Jetty9_v3.patch,
> HBASE-12894_Jetty9_v4.patch, HBASE-12894_Jetty9_v5.patch,
> HBASE-12894_Jetty9_v6.patch, HBASE-12894_Jetty9_v7.patch,
> HBASE-12894_Jetty9_v8.patch
>
>
> The Jetty component that is used for the HBase Stargate REST endpoint is
> version 6.1.26 and is fairly outdated. We recently had a customer inquire
> about enabling cross-origin resource sharing (CORS) for the REST endpoint and
> found that this older version does not include the necessary filter or
> configuration options, highlighted at:
> http://wiki.eclipse.org/Jetty/Feature/Cross_Origin_Filter
> The Jetty project has had significant updates through versions 7, 8 and 9,
> including a transition to be an Eclipse subproject, so updating to the latest
> version may be non-trivial. The last update to the Jetty component in
> https://issues.apache.org/jira/browse/HBASE-3377 was a minor version update
> and did not require significant work. This update will include a package
> namespace update so there will likely be a larger number of required changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830938#comment-15830938
]
Hadoop QA commented on HBASE-17462:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 10s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
36s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 4s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 81m 47s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 116m 40s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.balancer.TestStochasticLoadBalancer |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848406/HBASE-17642.patch |
| JIRA Issue | HBASE-17462 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 099c7ff95490 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 76dc957 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/5349/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/5349/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/5349/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/5349/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Investigate using sliding window for read/write request costs in
> StochasticLoadBalancer
>
[jira] [Commented] (HBASE-17381) ReplicationSourceWorkerThread can die due to unhandled exceptions
[
https://issues.apache.org/jira/browse/HBASE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830926#comment-15830926
]
Gary Helmling commented on HBASE-17381:
---
[~openinx] Thanks for the patch. This is an improvement.
Do you think it ever makes sense to let the ReplicationSourceWorkerThread die
and not abort the regionserver? In this case, replication will simply stop
with little visibility into it happening.
It seems better to me to just always abort in the case of an unexpected
Throwable thrown from runLoop(). Anything recoverable should be handled in a
try/catch in runLoop itself.
> ReplicationSourceWorkerThread can die due to unhandled exceptions
> -
>
> Key: HBASE-17381
> URL: https://issues.apache.org/jira/browse/HBASE-17381
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Gary Helmling
>Assignee: huzheng
> Attachments: HBASE-17381.patch
>
>
> If a ReplicationSourceWorkerThread encounters an unexpected exception in the
> run() method (for example failure to allocate direct memory for the DFS
> client), the exception will be logged by the UncaughtExceptionHandler, but
> the thread will also die and the replication queue will back up indefinitely
> until the Regionserver is restarted.
> We should make sure the worker thread is resilient to all exceptions that it
> can actually handle. For those that it really can't, it seems better to
> abort the regionserver rather than just allow replication to stop with
> minimal signal.
> Here is a sample exception:
> {noformat}
> ERROR regionserver.ReplicationSource: Unexpected exception in
> ReplicationSourceWorkerThread,
> currentPath=hdfs://.../hbase/WALs/XXXwalfilenameXXX
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:693)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:96)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:113)
> at
> org.apache.hadoop.crypto.CryptoOutputStream.(CryptoOutputStream.java:108)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.createStreamPair(DataTransferSaslUtil.java:344)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.doSaslHandshake(SaslDataTransferClient.java:490)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.getSaslStreams(SaslDataTransferClient.java:391)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.send(SaslDataTransferClient.java:263)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.checkTrustAndSend(SaslDataTransferClient.java:211)
> at
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient.peerSend(SaslDataTransferClient.java:160)
> at
> org.apache.hadoop.hdfs.net.TcpPeerServer.peerFromSocketAndKey(TcpPeerServer.java:92)
> at org.apache.hadoop.hdfs.DFSClient.newConnectedPeer(DFSClient.java:3444)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.nextTcpPeer(BlockReaderFactory.java:778)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.getRemoteBlockReaderFromTcp(BlockReaderFactory.java:695)
> at
> org.apache.hadoop.hdfs.BlockReaderFactory.build(BlockReaderFactory.java:356)
> at org.apache.hadoop.hdfs.DFSInputStream.blockSeekTo(DFSInputStream.java:673)
> at
> org.apache.hadoop.hdfs.DFSInputStream.readWithStrategy(DFSInputStream.java:882)
> at org.apache.hadoop.hdfs.DFSInputStream.read(DFSInputStream.java:934)
> at java.io.DataInputStream.read(DataInputStream.java:100)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:308)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:276)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:264)
> at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:423)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationWALReaderManager.openReader(ReplicationWALReaderManager.java:70)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.openReader(ReplicationSource.java:830)
> at
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:572)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: after_changes.png > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: before_changes.png > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: after_changes.png, before_changes.png, HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16831) Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock
[ https://issues.apache.org/jira/browse/HBASE-16831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16831: -- Resolution: Fixed Hadoop Flags: Reviewed Release Note: Purges code that did zk-hosted locks for table ops (we do procedure-based locks now) Status: Resolved (was: Patch Available) Pushed. The test passes locally (and change is unrelated). Will keep an eye on it. > Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock > > > Key: HBASE-16831 > URL: https://issues.apache.org/jira/browse/HBASE-16831 > Project: HBase > Issue Type: Sub-task >Reporter: Appy >Assignee: Appy >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-16831.master.001.patch, > HBASE-16831.master.002.patch > > > HBASE-16786 removes all uses of zk locks. Can delete the zk lock > implementation now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17491) Remove all setters from HTable interface and introduce a TableBuilder to build Table instance
[
https://issues.apache.org/jira/browse/HBASE-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830911#comment-15830911
]
Ted Yu commented on HBASE-17491:
Patch v3 looks good.
> Remove all setters from HTable interface and introduce a TableBuilder to
> build Table instance
> -
>
> Key: HBASE-17491
> URL: https://issues.apache.org/jira/browse/HBASE-17491
> Project: HBase
> Issue Type: Sub-task
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17491.patch, HBASE-17491.v2.patch,
> HBASE-17491.v3.patch
>
>
> As titled, we will remove all setters in HTable for master branch and
> deprecate them for branch-1 to make HTable thread-safe. And a new
> {{TableBuilder}} interface will be introduced to build Table instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17491) Remove all setters from HTable interface and introduce a TableBuilder to build Table instance
[
https://issues.apache.org/jira/browse/HBASE-17491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830905#comment-15830905
]
Yu Li commented on HBASE-17491:
---
UT looks good, and will revert the trivial change for triggering hbase-server
UT when commit. [~tedyu] could you take another look? Thanks.
ping [~stack] [~Apache9], any comments for this one? Thanks.
> Remove all setters from HTable interface and introduce a TableBuilder to
> build Table instance
> -
>
> Key: HBASE-17491
> URL: https://issues.apache.org/jira/browse/HBASE-17491
> Project: HBase
> Issue Type: Sub-task
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17491.patch, HBASE-17491.v2.patch,
> HBASE-17491.v3.patch
>
>
> As titled, we will remove all setters in HTable for master branch and
> deprecate them for branch-1 to make HTable thread-safe. And a new
> {{TableBuilder}} interface will be introduced to build Table instance
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16867) Procedure V2 - Check ACLs for remote HBaseLock
[ https://issues.apache.org/jira/browse/HBASE-16867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16867: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Release Note: Add checking ACL when taking locks. Status: Resolved (was: Patch Available) Pushed to master. > Procedure V2 - Check ACLs for remote HBaseLock > -- > > Key: HBASE-16867 > URL: https://issues.apache.org/jira/browse/HBASE-16867 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0 > > Attachments: HBASE-16867.master.001.patch, > HBASE-16867.master.002.patch, HBASE-16867.master.003.patch, > HBASE-16867.master.004.patch, HBASE-16867.master.005.patch > > > HBaseLock was added in HBASE-16744 to allow clients to take locks on > namespace/table/regions. Check acls for the 2 rpcs that were added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17067: -- Affects Version/s: 2.0.0 Status: Patch Available (was: Open) > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17059) backport HBASE-17039 to 1.3.1
[ https://issues.apache.org/jira/browse/HBASE-17059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830898#comment-15830898 ] Yu Li commented on HBASE-17059: --- I see, will start the already opened JIRA for backporting. Thanks for the confirmation sir [~mantonov] > backport HBASE-17039 to 1.3.1 > - > > Key: HBASE-17059 > URL: https://issues.apache.org/jira/browse/HBASE-17059 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 1.3.0 >Reporter: Yu Li >Assignee: Yu Li > Fix For: 1.3.1 > > > Currently branch-1.3 codes are freezing for 1.3.0 release, need to backport > HBASE-17039 to 1.3.1 afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830896#comment-15830896 ] stack commented on HBASE-17067: --- New version melds in what was up on rb https://reviews.apache.org/r/54435/ > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17067) Procedure v2 - remove zklock/tryLock and use wait/wake
[ https://issues.apache.org/jira/browse/HBASE-17067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17067: -- Attachment: HBASE-17067.master.002.patch > Procedure v2 - remove zklock/tryLock and use wait/wake > -- > > Key: HBASE-17067 > URL: https://issues.apache.org/jira/browse/HBASE-17067 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 2.0.0 > > Attachments: HBASE-17067.master.001.patch, > HBASE-17067.master.002.patch > > > Once we have HBASE-16744, HBASE-16786, HBASE-16831. we can remove the > tryLock() methods and replace them with the wait/wake methods that are using > the framework events instead of spinning until we can start the proc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17494) Guard against cloning family of all cells if no data need be replicated
[
https://issues.apache.org/jira/browse/HBASE-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17494:
---
Resolution: Fixed
Assignee: ChiaPing Tsai
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> Guard against cloning family of all cells if no data need be replicated
> ---
>
> Key: HBASE-17494
> URL: https://issues.apache.org/jira/browse/HBASE-17494
> Project: HBase
> Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Trivial
> Fix For: 1.4.0
>
> Attachments: HBASE-17494.branch-1.v0.patch
>
>
> The replication is enabled by default, so we try to clone the family of all
> cells even if there is no replication at all.
> {noformat}
> family = CellUtil.cloneFamily(cell);
> // Unexpected, has a tendency to happen in unit tests
> assert htd.getFamily(family) != null;
> if (!scopes.containsKey(family)) {
> int scope = htd.getFamily(family).getScope();
> if (scope != REPLICATION_SCOPE_LOCAL) {
> scopes.put(family, scope);
> }
> }
> {noformat}
> HBASE-15205 had resolved this issue, but it is committed to master only.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17494) Guard against cloning family of all cells if no data need be replicated
[
https://issues.apache.org/jira/browse/HBASE-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830881#comment-15830881
]
Ted Yu commented on HBASE-17494:
Test failure was not related to replication.
> Guard against cloning family of all cells if no data need be replicated
> ---
>
> Key: HBASE-17494
> URL: https://issues.apache.org/jira/browse/HBASE-17494
> Project: HBase
> Issue Type: Improvement
>Reporter: ChiaPing Tsai
>Priority: Trivial
> Fix For: 1.4.0
>
> Attachments: HBASE-17494.branch-1.v0.patch
>
>
> The replication is enabled by default, so we try to clone the family of all
> cells even if there is no replication at all.
> {noformat}
> family = CellUtil.cloneFamily(cell);
> // Unexpected, has a tendency to happen in unit tests
> assert htd.getFamily(family) != null;
> if (!scopes.containsKey(family)) {
> int scope = htd.getFamily(family).getScope();
> if (scope != REPLICATION_SCOPE_LOCAL) {
> scopes.put(family, scope);
> }
> }
> {noformat}
> HBASE-15205 had resolved this issue, but it is committed to master only.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16261) MultiHFileOutputFormat Enhancement
[
https://issues.apache.org/jira/browse/HBASE-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830872#comment-15830872
]
Hadoop QA commented on HBASE-16261:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 14s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 37s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 3s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 87m 18s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 124m 11s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Nullcheck of conn at line 345 of value previously dereferenced in
org.apache.hadoop.hbase.mapreduce.MultiHFileOutputFormat$MultiHFilePartitioner.getTablesRegionStartKeys(Configuration,
List) At MultiHFileOutputFormat.java:345 of value previously dereferenced in
org.apache.hadoop.hbase.mapreduce.MultiHFileOutputFormat$MultiHFilePartitioner.getTablesRegionStartKeys(Configuration,
List) At MultiHFileOutputFormat.java:[line 345] |
| Timed out junit tests | org.apache.hadoop.hbase.client.TestAsyncTableBatch |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12848393/HBase-16261-V8.patch |
| JIRA Issue | HBASE-16261 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 709d6fa36895 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 76dc957 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| findbugs |
https://builds.apache.org/job/PreCommit-HBASE-Build/5345/artifact/patchprocess/new-findbugs-hbase-server.html
|
| unit |
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830866#comment-15830866 ] Ted Yu commented on HBASE-17462: Please attach the screen shots. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830861#comment-15830861 ] Tim Brown commented on HBASE-17462: --- The regionLoadList has a configurable size. By default it is 15 and controlled by `hbase.master.balancer.stochastic.numRegionLoadsToRemember`. For performance, I can attach some screenshots of charts that look at the average number of requests per region server. If you want more in depth analysis let me know. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830861#comment-15830861 ] Tim Brown edited comment on HBASE-17462 at 1/20/17 12:05 AM: - The regionLoadList has a configurable size. By default it is 15 and controlled by "hbase.master.balancer.stochastic.numRegionLoadsToRemember". For performance, I can attach some screenshots of charts that look at the average number of requests per region server. If you want more in depth analysis let me know. was (Author: timbrown): The regionLoadList has a configurable size. By default it is 15 and controlled by `hbase.master.balancer.stochastic.numRegionLoadsToRemember`. For performance, I can attach some screenshots of charts that look at the average number of requests per region server. If you want more in depth analysis let me know. > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: (was: HBASE-17642.patch) > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: HBASE-17462.patch > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17462.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16831) Procedure V2 - Remove org.apache.hadoop.hbase.zookeeper.lock
[
https://issues.apache.org/jira/browse/HBASE-16831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830842#comment-15830842
]
Hadoop QA commented on HBASE-16831:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 13s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 13s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
4s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 9s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
33s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 54s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 26s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
7s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 2s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 28s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 2m
59s {color} | {color:green} the patch passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 24s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 15s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 25s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 77m 20s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 93m 25s {color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
46s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 243m 57s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit
[jira] [Commented] (HBASE-16786) Procedure V2 - Move ZK-lock's uses to Procedure framework locks (LockProcedure)
[ https://issues.apache.org/jira/browse/HBASE-16786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830834#comment-15830834 ] Hudson commented on HBASE-16786: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2349 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2349/]) HBASE-16786 Procedure V2 - Move ZK-lock's uses to Procedure framework (stack: rev 76dc957f64fa38ce88694054db7dbf590f368ae7) * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/master/TableLockManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMobStoreCompaction.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/locking/LockManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureScheduler.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HMobStore.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockNoopMasterServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MobCompactionChore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactSplitThread.java * (edit) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java * (edit) hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/ProcedureExecutor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureSchedulerConcurrency.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/MockRegionServerServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/client/locking/EntityLock.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/locking/TestLockProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureSchedulerPerformanceEvaluation.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerMetrics.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterMobCompactionThread.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckOneRS.java * (edit) hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureSuspended.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/locking/LockProcedure.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterServices.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestTableLockManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestMasterObserver.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/TableLockChecker.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/ExpiredMobFileCleanerChore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureUtil.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/mob/MobUtils.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServerFactory.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureScheduler.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/TakeSnapshotHandler.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestTokenAuthentication.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMergeTableRegionsProcedure.java > Procedure V2 - Move ZK-lock's uses to Procedure framework locks > (LockProcedure) > --- > > Key: HBASE-16786 > URL: https://issues.apache.org/jira/browse/HBASE-16786 > Project: HBase > Issue Type: Sub-task >Reporter:
[jira] [Commented] (HBASE-17280) Add mechanism to control hbase cleaner behavior
[
https://issues.apache.org/jira/browse/HBASE-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830822#comment-15830822
]
Hadoop QA commented on HBASE-17280:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 31s
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 1s
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 1s
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 5m 14s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
25s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 53s
{color} | {color:green} branch-1.2 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 59s
{color} | {color:green} branch-1.2 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
58s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
19s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
39s {color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 28s
{color} | {color:green} branch-1.2 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 38s
{color} | {color:green} branch-1.2 passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 58s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 58s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 58s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
22m 20s {color} | {color:green} The patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
27s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 28s
{color} | {color:red} hbase-client-jdk1.8.0_111 with JDK v1.8.0_111 generated 2
new + 12 unchanged - 0 fixed = 14 total (was 12) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 29s
{color} | {color:red} hbase-client-jdk1.7.0_80 with JDK v1.7.0_80 generated 2
new + 12 unchanged - 0 fixed = 14 total (was 12) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 28s
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 50s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red}
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830817#comment-15830817
]
Ted Yu commented on HBASE-17462:
The JIRA number is 17462. Please name your patch accordingly.
{code}
testRegionLoadCost(org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer)
Time elapsed: 0.235 sec <<< FAILURE!
java.lang.AssertionError: expected:<2.5> but was:<1.0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:553)
at org.junit.Assert.assertEquals(Assert.java:683)
at
org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer.testRegionLoadCost(TestStochasticLoadBalancer.java:255)
{code}
Please investigate the above unit test failure.
> Investigate using sliding window for read/write request costs in
> StochasticLoadBalancer
> ---
>
> Key: HBASE-17462
> URL: https://issues.apache.org/jira/browse/HBASE-17462
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Tim Brown
> Labels: patch
> Attachments: HBASE-17642.patch
>
>
> In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was
> asking whether the read/write request costs in StochasticLoadBalancer should
> be calculated as rates.
> This makes sense since read / write load on region server tends to fluctuate
> over time. Using sliding window would reflect more recent trend in read /
> write load.
> Some factors to consider:
> The data structure used by StochasticLoadBalancer should be concise. The
> number of regions in a cluster can be expected to approach 1 million. We
> cannot afford to store long history of read / write requests in master.
> Efficiency of cost calculation should be high - there're many cost
> functions the balancer goes through, it is expected for each cost function
> to return quickly. Otherwise we would not come up with proper region
> movement plan(s) in time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16998) [Master] Analyze table use reports and update quota violations
[ https://issues.apache.org/jira/browse/HBASE-16998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-16998: --- Attachment: HBASE-16998.003.HBASE-16961.patch .003 Fixes a bug in QuotaObserverChore which would prevent it from triggering quota updates to RS's. > [Master] Analyze table use reports and update quota violations > -- > > Key: HBASE-16998 > URL: https://issues.apache.org/jira/browse/HBASE-16998 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-16998.001.patch, > HBASE-16998.002.HBASE-16961.patch, HBASE-16998.003.HBASE-16961.patch > > > Given the collected table usage reports from RegionServers, the Master needs > to inspect all filesystem-use quotas and determine which need to move into > violation and which need to move out of violation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17481) [C++] cpplint should use line wrapping of 100
[ https://issues.apache.org/jira/browse/HBASE-17481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830791#comment-15830791 ] Enis Soztutar commented on HBASE-17481: --- Thanks Sudeep. Pushed this to branch. > [C++] cpplint should use line wrapping of 100 > - > > Key: HBASE-17481 > URL: https://issues.apache.org/jira/browse/HBASE-17481 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Fix For: HBASE-14850 > > Attachments: HBASE-17481.HBASE-14850.v1.patch > > > We have changed the line wrapping to 100. cpplint should reflect the same to > avoid unnecessary warnings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[
https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830789#comment-15830789
]
Ted Yu commented on HBASE-17462:
{code}
+ for (RegionLoad rl : regionLoadList) {
+double current = getCostFromRl(rl);
+if (previous != null) {
+ cost += current - previous;
+}
+previous = current;
{code}
(Through debug logging) what is length of regionLoadList for the read / write
requests ?
The average length would give us some idea how many samples are taken for the
sliding window.
Can you share (improved) performance when you tested the change on your cluster
?
Thanks
> Investigate using sliding window for read/write request costs in
> StochasticLoadBalancer
> ---
>
> Key: HBASE-17462
> URL: https://issues.apache.org/jira/browse/HBASE-17462
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Tim Brown
> Labels: patch
> Attachments: HBASE-17642.patch
>
>
> In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was
> asking whether the read/write request costs in StochasticLoadBalancer should
> be calculated as rates.
> This makes sense since read / write load on region server tends to fluctuate
> over time. Using sliding window would reflect more recent trend in read /
> write load.
> Some factors to consider:
> The data structure used by StochasticLoadBalancer should be concise. The
> number of regions in a cluster can be expected to approach 1 million. We
> cannot afford to store long history of read / write requests in master.
> Efficiency of cost calculation should be high - there're many cost
> functions the balancer goes through, it is expected for each cost function
> to return quickly. Otherwise we would not come up with proper region
> movement plan(s) in time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17481) [C++] cpplint should use line wrapping of 100
[ https://issues.apache.org/jira/browse/HBASE-17481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-17481: -- Summary: [C++] cpplint should use line wrapping of 100 (was: [C++] Changing cpplint to ignore line wrapping warnings) > [C++] cpplint should use line wrapping of 100 > - > > Key: HBASE-17481 > URL: https://issues.apache.org/jira/browse/HBASE-17481 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Fix For: HBASE-14850 > > Attachments: HBASE-17481.HBASE-14850.v1.patch > > > We have changed the line wrapping to 100. cpplint should reflect the same to > avoid unnecessary warnings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17481) [C++] cpplint should use line wrapping of 100
[ https://issues.apache.org/jira/browse/HBASE-17481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-17481: -- Resolution: Fixed Fix Version/s: HBASE-14850 Status: Resolved (was: Patch Available) > [C++] cpplint should use line wrapping of 100 > - > > Key: HBASE-17481 > URL: https://issues.apache.org/jira/browse/HBASE-17481 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Fix For: HBASE-14850 > > Attachments: HBASE-17481.HBASE-14850.v1.patch > > > We have changed the line wrapping to 100. cpplint should reflect the same to > avoid unnecessary warnings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-15705) Add on meta cache.
[ https://issues.apache.org/jira/browse/HBASE-15705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-15705. --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: HBASE-14850 Pushed to branch. > Add on meta cache. > -- > > Key: HBASE-15705 > URL: https://issues.apache.org/jira/browse/HBASE-15705 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Fix For: HBASE-14850 > > Attachments: hbase-15705_v2.patch, native-client-meta-cache-v2.patch > > > We need to cache this stuff, and it needs to be fast. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16942) FavoredNodes - Balancer improvements
[ https://issues.apache.org/jira/browse/HBASE-16942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvel Thirumoolan updated HBASE-16942: - Status: Patch Available (was: In Progress) Uploading patch for precommit builds to run, not for review yet. > FavoredNodes - Balancer improvements > > > Key: HBASE-16942 > URL: https://issues.apache.org/jira/browse/HBASE-16942 > Project: HBase > Issue Type: Sub-task >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan > Fix For: 2.0.0 > > Attachments: HBASE-16942.master.001.patch, > HBASE-16942.master.002.patch, HBASE_16942_rough_draft.patch > > > This deals with the balancer based enhancements to favored nodes patch as > discussed in HBASE-15532. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-16942) FavoredNodes - Balancer improvements
[ https://issues.apache.org/jira/browse/HBASE-16942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-16942 started by Thiruvel Thirumoolan. > FavoredNodes - Balancer improvements > > > Key: HBASE-16942 > URL: https://issues.apache.org/jira/browse/HBASE-16942 > Project: HBase > Issue Type: Sub-task >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan > Fix For: 2.0.0 > > Attachments: HBASE-16942.master.001.patch, > HBASE-16942.master.002.patch, HBASE_16942_rough_draft.patch > > > This deals with the balancer based enhancements to favored nodes patch as > discussed in HBASE-15532. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16942) FavoredNodes - Balancer improvements
[ https://issues.apache.org/jira/browse/HBASE-16942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvel Thirumoolan updated HBASE-16942: - Attachment: HBASE-16942.master.002.patch > FavoredNodes - Balancer improvements > > > Key: HBASE-16942 > URL: https://issues.apache.org/jira/browse/HBASE-16942 > Project: HBase > Issue Type: Sub-task >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan > Fix For: 2.0.0 > > Attachments: HBASE-16942.master.001.patch, > HBASE-16942.master.002.patch, HBASE_16942_rough_draft.patch > > > This deals with the balancer based enhancements to favored nodes patch as > discussed in HBASE-15532. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15705) Add on meta cache.
[ https://issues.apache.org/jira/browse/HBASE-15705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15705: -- Attachment: hbase-15705_v2.patch Thanks Mikhail for the patch. As per offline discussion, I was able to fix the segfault and do a couple of more changes on top of your patch. Will commit this shortly: - Rebased & reformatted - Added more unit tests - Fixed the region lookup logic, and seg fault there. - Added some verbose logging - fixed assertions when closing the sockets from wangle. > Add on meta cache. > -- > > Key: HBASE-15705 > URL: https://issues.apache.org/jira/browse/HBASE-15705 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark > Attachments: hbase-15705_v2.patch, native-client-meta-cache-v2.patch > > > We need to cache this stuff, and it needs to be fast. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Labels: patch (was: ) Status: Patch Available (was: In Progress) > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Labels: patch > Attachments: HBASE-17642.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15705) Add on meta cache.
[ https://issues.apache.org/jira/browse/HBASE-15705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15705: -- Assignee: Mikhail Antonov > Add on meta cache. > -- > > Key: HBASE-15705 > URL: https://issues.apache.org/jira/browse/HBASE-15705 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Mikhail Antonov > Attachments: hbase-15705_v2.patch, native-client-meta-cache-v2.patch > > > We need to cache this stuff, and it needs to be fast. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-17462 started by Tim Brown. - > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Attachments: HBASE-17642.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: (was: hbase.patch) > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Attachments: HBASE-17642.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17462) Investigate using sliding window for read/write request costs in StochasticLoadBalancer
[ https://issues.apache.org/jira/browse/HBASE-17462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Brown updated HBASE-17462: -- Attachment: HBASE-17642.patch > Investigate using sliding window for read/write request costs in > StochasticLoadBalancer > --- > > Key: HBASE-17462 > URL: https://issues.apache.org/jira/browse/HBASE-17462 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Tim Brown > Attachments: HBASE-17642.patch > > > In the thread, http://search-hadoop.com/m/HBase/YGbbyUZKXWALkX1, Timothy was > asking whether the read/write request costs in StochasticLoadBalancer should > be calculated as rates. > This makes sense since read / write load on region server tends to fluctuate > over time. Using sliding window would reflect more recent trend in read / > write load. > Some factors to consider: > The data structure used by StochasticLoadBalancer should be concise. The > number of regions in a cluster can be expected to approach 1 million. We > cannot afford to store long history of read / write requests in master. > Efficiency of cost calculation should be high - there're many cost > functions the balancer goes through, it is expected for each cost function > to return quickly. Otherwise we would not come up with proper region > movement plan(s) in time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
