[jira] [Updated] (HBASE-17274) Add a server level throttler for replication sources
[ https://issues.apache.org/jira/browse/HBASE-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Yang updated HBASE-17274: -- Description: If we have many peers or some servers have many recovered queues, the total read size per second from WALs will be very high. So we should add a server level throttler to limit the total speed of reading WALs. was: If we have many peers or some servers have many recovered queues, the total read size per second from WALs will be very high, which will increase the pressure of GC, even maybe OOM because we will read entries for 64MB to buffer in default. So we should add a server level throttler to limit the speed of reading WALs, and limit the total buffered entries for all ReplicationSources. > Add a server level throttler for replication sources > > > Key: HBASE-17274 > URL: https://issues.apache.org/jira/browse/HBASE-17274 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Phil Yang >Assignee: Phil Yang > > If we have many peers or some servers have many recovered queues, the total > read size per second from WALs will be very high. > So we should add a server level throttler to limit the total speed of reading > WALs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-11392: --- Attachment: HBASE-11392-v2.patch > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch, HBASE-11392-v2.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17291) Remove ImmutableSegment#getKeyValueScanner
[
https://issues.apache.org/jira/browse/HBASE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747572#comment-15747572
]
Hadoop QA commented on HBASE-17291:
---
| (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} 2m
54s {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
45s {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 26s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {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}
26m 3s {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
54s {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:red}-1{color} | {color:red} unit {color} | {color:red} 94m 26s {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} 132m 31s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestCompactingMemStore |
| | hadoop.hbase.regionserver.TestCompactingToCellArrayMapMemStore |
\\
\\
|| 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/12843153/HBASE-17291_1.patch |
| JIRA Issue | HBASE-17291 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 57fa025120c9 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18
21:21:05 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 / a931043 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/4906/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/4906/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4906/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4906/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Remove ImmutableSegment#getKeyValueScanner
>
[jira] [Updated] (HBASE-17313) Add BufferedMutatorParams#clone method
[ https://issues.apache.org/jira/browse/HBASE-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joep Rottinghuis updated HBASE-17313: - Attachment: HBASE-17313.master.002.patch Attaching HBASE-17313.master.002.patch for the reconciliation bits with HBASE-17277, unless you want me to open a separate jira for that [~stack] For my purposes I need a BufferedMutatorParams without the implementationClassName cloned, but I think it would be rather unexpected for clone to leave one field out, so I think it is cleaner to include in clone (and the unit test) and then have the user wipe out whatever field they don't want from the clone. > Add BufferedMutatorParams#clone method > -- > > Key: HBASE-17313 > URL: https://issues.apache.org/jira/browse/HBASE-17313 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Joep Rottinghuis >Assignee: Joep Rottinghuis > Fix For: 2.0.0 > > Attachments: HBASE-17313.master.001.patch, > HBASE-17313.master.002.patch > > > In HBASE-17277 we allow an alternate BufferedMutator implementation. If we > want to use that and not make BufferedMutatorImpl public, we need to be able > to ask the connection to create us one. In that case, we need to clone the > params (and then strip one argument off). > This jira is to add a clone method for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-15432) TableInputFormat - support multiple column families scan
[
https://issues.apache.org/jira/browse/HBASE-15432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xuesen Liang updated HBASE-15432:
-
Comment: was deleted
(was: How about to reuse 'SCAN_COLUMN_FAMILY'?
For example, the following code in
org.apache.hadoop.hbase.mapreduce.TableInputFormat
{code}
if (conf.get(SCAN_COLUMN_FAMILY) != null) {
scan.addFamily(Bytes.toBytes(conf.get(SCAN_COLUMN_FAMILY)));
}
{code}
can be replaced by
{code}
for (String cf : conf.getTrimmedStrings(SCAN_COLUMN_FAMILY)) {
scan.addFamily(Bytes.toBytes(cf));
}
{code}
It is totally compatible.
)
> TableInputFormat - support multiple column families scan
>
>
> Key: HBASE-15432
> URL: https://issues.apache.org/jira/browse/HBASE-15432
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0, 0.98.16, 0.98.16.1
>Reporter: nirav patel
>
> Currently Hbase TableInputFormat class has SCAN_COLUMN_FAMILY and
> SCAN_COLUMNS. SCAN_COLUMN_FAMILY can only scan single column family. If we
> need to scan multiple column families from a table then we must use
> SCAN_COLUMNS where we must provide both columns and column families which is
> not a convenient. Can we have a SCAN_COLUMN_FAMILIES which supports scan of
> multiple column families.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15432) TableInputFormat - support multiple column families scan
[
https://issues.apache.org/jira/browse/HBASE-15432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747517#comment-15747517
]
Xuesen Liang commented on HBASE-15432:
--
How about to reuse 'SCAN_COLUMN_FAMILY'?
For example, the following code in
org.apache.hadoop.hbase.mapreduce.TableInputFormat
{code}
if (conf.get(SCAN_COLUMN_FAMILY) != null) {
scan.addFamily(Bytes.toBytes(conf.get(SCAN_COLUMN_FAMILY)));
}
{code}
can be replaced by
{code}
for (String cf : conf.getTrimmedStrings(SCAN_COLUMN_FAMILY)) {
scan.addFamily(Bytes.toBytes(cf));
}
{code}
It is totally compatible.
> TableInputFormat - support multiple column families scan
>
>
> Key: HBASE-15432
> URL: https://issues.apache.org/jira/browse/HBASE-15432
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0, 0.98.16, 0.98.16.1
>Reporter: nirav patel
>
> Currently Hbase TableInputFormat class has SCAN_COLUMN_FAMILY and
> SCAN_COLUMNS. SCAN_COLUMN_FAMILY can only scan single column family. If we
> need to scan multiple column families from a table then we must use
> SCAN_COLUMNS where we must provide both columns and column families which is
> not a convenient. Can we have a SCAN_COLUMN_FAMILIES which supports scan of
> multiple column families.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15432) TableInputFormat - support multiple column families scan
[
https://issues.apache.org/jira/browse/HBASE-15432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747519#comment-15747519
]
Xuesen Liang commented on HBASE-15432:
--
How about to reuse 'SCAN_COLUMN_FAMILY'?
For example, the following code in
org.apache.hadoop.hbase.mapreduce.TableInputFormat
{code}
if (conf.get(SCAN_COLUMN_FAMILY) != null) {
scan.addFamily(Bytes.toBytes(conf.get(SCAN_COLUMN_FAMILY)));
}
{code}
can be replaced by
{code}
for (String cf : conf.getTrimmedStrings(SCAN_COLUMN_FAMILY)) {
scan.addFamily(Bytes.toBytes(cf));
}
{code}
It is totally compatible.
> TableInputFormat - support multiple column families scan
>
>
> Key: HBASE-15432
> URL: https://issues.apache.org/jira/browse/HBASE-15432
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0, 0.98.16, 0.98.16.1
>Reporter: nirav patel
>
> Currently Hbase TableInputFormat class has SCAN_COLUMN_FAMILY and
> SCAN_COLUMNS. SCAN_COLUMN_FAMILY can only scan single column family. If we
> need to scan multiple column families from a table then we must use
> SCAN_COLUMNS where we must provide both columns and column families which is
> not a convenient. Can we have a SCAN_COLUMN_FAMILIES which supports scan of
> multiple column families.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17313) Add BufferedMutatorParams#clone method
[
https://issues.apache.org/jira/browse/HBASE-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747511#comment-15747511
]
Hadoop QA commented on HBASE-17313:
---
| (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
41s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{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
9s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
9s {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 16s {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} 0m 54s
{color} | {color:red} hbase-client generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 0s
{color} | {color:green} hbase-client 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} 31m 19s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-client |
| | org.apache.hadoop.hbase.client.BufferedMutatorParams defines clone() but
doesn't implement Cloneable At BufferedMutatorParams.java:implement Cloneable
At BufferedMutatorParams.java:[lines 117-122] |
\\
\\
|| 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/12843159/HBASE-17313.master.001.patch
|
| JIRA Issue | HBASE-17313 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 8837a447c86f 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 / a931043 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| findbugs |
https://builds.apache.org/job/PreCommit-HBASE-Build/4907/artifact/patchprocess/new-findbugs-hbase-client.html
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4907/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4907/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Add BufferedMutatorParams#clone method
>
[jira] [Updated] (HBASE-17081) Flush the entire CompactingMemStore content to disk
[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17081: --- Status: Open (was: Patch Available) > Flush the entire CompactingMemStore content to disk > --- > > Key: HBASE-17081 > URL: https://issues.apache.org/jira/browse/HBASE-17081 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, > HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, > HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, > HBaseMeetupDecember2016-V02.pptx, Pipelinememstore_fortrunk_3.patch > > > Part of CompactingMemStore's memory is held by an active segment, and another > part is divided between immutable segments in the compacting pipeline. Upon > flush-to-disk request we want to flush all of it to disk, in contrast to > flushing only tail of the compacting pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17081) Flush the entire CompactingMemStore content to disk
[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17081: --- Status: Patch Available (was: Open) > Flush the entire CompactingMemStore content to disk > --- > > Key: HBASE-17081 > URL: https://issues.apache.org/jira/browse/HBASE-17081 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, > HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, > HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, > HBaseMeetupDecember2016-V02.pptx, Pipelinememstore_fortrunk_3.patch > > > Part of CompactingMemStore's memory is held by an active segment, and another > part is divided between immutable segments in the compacting pipeline. Upon > flush-to-disk request we want to flush all of it to disk, in contrast to > flushing only tail of the compacting pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17081) Flush the entire CompactingMemStore content to disk
[ https://issues.apache.org/jira/browse/HBASE-17081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17081: --- Attachment: HBASE-15787_8.patch Previous patch had a test case compilation issue. I will check with Anoop on one of his comments and after that will go for the commit. Thanks [~saint@gmail.com] for your +1. > Flush the entire CompactingMemStore content to disk > --- > > Key: HBASE-17081 > URL: https://issues.apache.org/jira/browse/HBASE-17081 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky > Attachments: HBASE-15787_8.patch, HBASE-17081-V01.patch, > HBASE-17081-V02.patch, HBASE-17081-V03.patch, HBASE-17081-V04.patch, > HBASE-17081-V05.patch, HBASE-17081-V06.patch, HBASE-17081-V06.patch, > HBaseMeetupDecember2016-V02.pptx, Pipelinememstore_fortrunk_3.patch > > > Part of CompactingMemStore's memory is held by an active segment, and another > part is divided between immutable segments in the compacting pipeline. Upon > flush-to-disk request we want to flush all of it to disk, in contrast to > flushing only tail of the compacting pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747493#comment-15747493 ] stack commented on HBASE-17018: --- HBASE-17313 and HBASE-17277 were pushed. Hope I think I got it right. ExceptionListener seems like good idea -- especially if it will help this project. > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17313) Add BufferedMutatorParams#clone method
[ https://issues.apache.org/jira/browse/HBASE-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17313: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Pushed to master. Needed some fixup after HBASE-17277 went in. Tried test locally and passed. Thanks for the patch [~jrottinghuis] > Add BufferedMutatorParams#clone method > -- > > Key: HBASE-17313 > URL: https://issues.apache.org/jira/browse/HBASE-17313 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Joep Rottinghuis >Assignee: Joep Rottinghuis > Fix For: 2.0.0 > > Attachments: HBASE-17313.master.001.patch > > > In HBASE-17277 we allow an alternate BufferedMutator implementation. If we > want to use that and not make BufferedMutatorImpl public, we need to be able > to ask the connection to create us one. In that case, we need to clone the > params (and then strip one argument off). > This jira is to add a clone method for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17277) Allow alternate BufferedMutator implementation
[ https://issues.apache.org/jira/browse/HBASE-17277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17277: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Pushed to master. Thanks for the review [~jrottinghuis]. We can amend in new JIRA if you need more. Leaving it master for now. When all working for you, lets then backport. > Allow alternate BufferedMutator implementation > -- > > Key: HBASE-17277 > URL: https://issues.apache.org/jira/browse/HBASE-17277 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17277.master.001.patch, > HBASE-17277.master.002.patch > > > Allow being able to supply alternate BufferedMutator implementation. For > example, the parent issue would like to spool writes to the filesystem if > hbase is down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16398) optimize HRegion computeHDFSBlocksDistribution
[
https://issues.apache.org/jira/browse/HBASE-16398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747456#comment-15747456
]
Hadoop QA commented on HBASE-16398:
---
| (x) *{color:red}-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: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} 2m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s {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
40s {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
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
44s {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 38s {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
47s {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} 90m 34s
{color} | {color:green} hbase-server in the patch passed. {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} 127m 51s {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/12843151/HBASE-16398_v5.patch |
| JIRA Issue | HBASE-16398 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 841ed01de426 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 / a931043 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4905/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4905/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> optimize HRegion computeHDFSBlocksDistribution
> --
>
> Key: HBASE-16398
> URL: https://issues.apache.org/jira/browse/HBASE-16398
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter:
[jira] [Commented] (HBASE-17277) Allow alternate BufferedMutator implementation
[ https://issues.apache.org/jira/browse/HBASE-17277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747445#comment-15747445 ] Joep Rottinghuis commented on HBASE-17277: -- This patch looks good to me, modulo the dependency on HBASE-17313, or its dependency on this jira, whichever order we want to apply them. > Allow alternate BufferedMutator implementation > -- > > Key: HBASE-17277 > URL: https://issues.apache.org/jira/browse/HBASE-17277 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Attachments: HBASE-17277.master.001.patch, > HBASE-17277.master.002.patch > > > Allow being able to supply alternate BufferedMutator implementation. For > example, the parent issue would like to spool writes to the filesystem if > hbase is down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747443#comment-15747443 ] Joep Rottinghuis commented on HBASE-17018: -- Filed HBASE-17313 with patch. If HBASE-17313 goes in first, then HBASE-17277 should be updated to add the new field in the clone method (and in the unit test comparison), or visa versa. bq. Is there anything point in AP that could be exposed that might help simplify the implementation at all? Good question. Not quite sure. I was thinking of adding two more things: a) an exception listener that can be used to capture exceptions from the BufferedMutatorImpl and pass them to the coordinator. I'll have to see if it is clear for the submission to catch these and shove all of this info into the Future to pass back, or if I want to have this all appear asynchronously in the coordinator. I think the former might be cleaner. b) If the outbound queue reaches a certain size it should trigger a flush. As [~sjlee0] pointed out, the current design would allow for the outbound queue to grow very large if the user keeps sending mutations without calling flush. The BufferdMutatorImpl could have flushed, but we don't know that. I think the cleanest solution would be to call flush, but that cannot be a blocking call from the processor, otherwise we'll have a deadlock on our hands. I probably have to make flush on the SpoolingBufferedMutatorImpl have a boolean argument to block or not block. Perhaps this is a bit where modifying the AP or the BMI to indicate that a size-based flush happened might be a good thing. On the other hand, to treat the BMI as a total black-box has a certain elegance... > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17313) Add BufferedMutatorParams#clone method
[ https://issues.apache.org/jira/browse/HBASE-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joep Rottinghuis updated HBASE-17313: - Status: Patch Available (was: Open) > Add BufferedMutatorParams#clone method > -- > > Key: HBASE-17313 > URL: https://issues.apache.org/jira/browse/HBASE-17313 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Joep Rottinghuis >Assignee: Joep Rottinghuis > Attachments: HBASE-17313.master.001.patch > > > In HBASE-17277 we allow an alternate BufferedMutator implementation. If we > want to use that and not make BufferedMutatorImpl public, we need to be able > to ask the connection to create us one. In that case, we need to clone the > params (and then strip one argument off). > This jira is to add a clone method for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17313) Add BufferedMutatorParams#clone method
[ https://issues.apache.org/jira/browse/HBASE-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joep Rottinghuis updated HBASE-17313: - Attachment: HBASE-17313.master.001.patch > Add BufferedMutatorParams#clone method > -- > > Key: HBASE-17313 > URL: https://issues.apache.org/jira/browse/HBASE-17313 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Joep Rottinghuis >Assignee: Joep Rottinghuis > Attachments: HBASE-17313.master.001.patch > > > In HBASE-17277 we allow an alternate BufferedMutator implementation. If we > want to use that and not make BufferedMutatorImpl public, we need to be able > to ask the connection to create us one. In that case, we need to clone the > params (and then strip one argument off). > This jira is to add a clone method for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17313) Add BufferedMutatorParams#clone method
Joep Rottinghuis created HBASE-17313: Summary: Add BufferedMutatorParams#clone method Key: HBASE-17313 URL: https://issues.apache.org/jira/browse/HBASE-17313 Project: HBase Issue Type: Sub-task Components: Client Reporter: Joep Rottinghuis Assignee: Joep Rottinghuis In HBASE-17277 we allow an alternate BufferedMutator implementation. If we want to use that and not make BufferedMutatorImpl public, we need to be able to ask the connection to create us one. In that case, we need to clone the params (and then strip one argument off). This jira is to add a clone method for convenience. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-16851) User-facing documentation for the In-Memory Compaction feature
[ https://issues.apache.org/jira/browse/HBASE-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16851: -- Assignee: Edward Bortnikov > User-facing documentation for the In-Memory Compaction feature > -- > > Key: HBASE-16851 > URL: https://issues.apache.org/jira/browse/HBASE-16851 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Edward Bortnikov >Assignee: Edward Bortnikov > Attachments: Accordion HBase In-Memory Compaction - Nov 1 .pdf, > Accordion HBase In-Memory Compaction - Nov 23.pdf, Accordion_ HBase In-Memory > Compaction - Oct 27.pdf, HBaseAcceleratedHbaseConf-final.pptx > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747398#comment-15747398 ] Guanghao Zhang commented on HBASE-11392: Sorry, not rebase the latest codebase... Will upload a v2 patch later. > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-9774) Provide a way for coprocessors to register and report custom metrics
[ https://issues.apache.org/jira/browse/HBASE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-9774: - Attachment: hbase-9774_v3.patch v3 should fix the unit test and other hadoopqa problems. Let's see how this does. > Provide a way for coprocessors to register and report custom metrics > > > Key: HBASE-9774 > URL: https://issues.apache.org/jira/browse/HBASE-9774 > Project: HBase > Issue Type: New Feature > Components: Coprocessors, metrics >Reporter: Gary Helmling >Assignee: Enis Soztutar > Attachments: hbase-9774_v1.patch, hbase-9774_v3.patch > > > It would help provide better visibility into what coprocessors are doing if > we provided a way for coprocessors to export their own metrics. The general > idea is to: > * extend access to the HBase "metrics bus" down into the coprocessor > environments > * coprocessors can then register and increment custom metrics > * coprocessor metrics are then reported along with all others through normal > mechanisms -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17291) Remove ImmutableSegment#getKeyValueScanner
[ https://issues.apache.org/jira/browse/HBASE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17291: --- Status: Patch Available (was: Open) > Remove ImmutableSegment#getKeyValueScanner > -- > > Key: HBASE-17291 > URL: https://issues.apache.org/jira/browse/HBASE-17291 > Project: HBase > Issue Type: Improvement > Components: Scanners >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-17291.patch, HBASE-17291_1.patch > > > This is based on a discussion over [~anastas]'s patch. The MemstoreSnapshot > uses a KeyValueScanner which actually seems redundant considering we already > have a SegmentScanner. The idea is that the snapshot scanner should be a > simple iterator type of scanner but it lacks the capability to do the > reference counting on that segment that is now used in snapshot. With > snapshot having mulitple segments in the latest impl it is better we hold on > to the segment by doing ref counting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17291) Remove ImmutableSegment#getKeyValueScanner
[ https://issues.apache.org/jira/browse/HBASE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17291: --- Attachment: HBASE-17291_1.patch [~anastas]- Pls take a look at this. Once HBASE-17081 goes in I think we can rebase this patch and ensure all the test cases in HBASE-17081 passes. > Remove ImmutableSegment#getKeyValueScanner > -- > > Key: HBASE-17291 > URL: https://issues.apache.org/jira/browse/HBASE-17291 > Project: HBase > Issue Type: Improvement > Components: Scanners >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-17291.patch, HBASE-17291_1.patch > > > This is based on a discussion over [~anastas]'s patch. The MemstoreSnapshot > uses a KeyValueScanner which actually seems redundant considering we already > have a SegmentScanner. The idea is that the snapshot scanner should be a > simple iterator type of scanner but it lacks the capability to do the > reference counting on that segment that is now used in snapshot. With > snapshot having mulitple segments in the latest impl it is better we hold on > to the segment by doing ref counting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17291) Remove ImmutableSegment#getKeyValueScanner
[ https://issues.apache.org/jira/browse/HBASE-17291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-17291: --- Status: Open (was: Patch Available) > Remove ImmutableSegment#getKeyValueScanner > -- > > Key: HBASE-17291 > URL: https://issues.apache.org/jira/browse/HBASE-17291 > Project: HBase > Issue Type: Improvement > Components: Scanners >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-17291.patch > > > This is based on a discussion over [~anastas]'s patch. The MemstoreSnapshot > uses a KeyValueScanner which actually seems redundant considering we already > have a SegmentScanner. The idea is that the snapshot scanner should be a > simple iterator type of scanner but it lacks the capability to do the > reference counting on that segment that is now used in snapshot. With > snapshot having mulitple segments in the latest impl it is better we hold on > to the segment by doing ref counting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747317#comment-15747317 ] stack commented on HBASE-17018: --- bq, I don't want those attributes to be transmitted to HBase, that would be a waste. The bit where you'd have to peel-apart-a-submission to mark all Mutations kills my suggestion I'd say. bq. Is that a question or statement? If the HBase community is interested to have this part of HBase, that would be great and I'll continue the code in place. If not, then I'll move this to yarn. Question. IMO, it is an exotic feature. Lets see if anyone else interested. If not, probably better have it live w/ TimelineV2. bq. Reformatting javadoc wasn't intended. I'll remove that. In fact, I'll file a separate sub-jira to just add the clone method to the BufferedMutatorParams to separate out that concern. Good. Lets get that in. Patch looks great so far. Is there anything point in AP that could be exposed that might help simplify the implementation at all? Your approach of treating BMI as black box is probably best way to go... justifies all the rigging you have about... rigging that you'd probably end up building anyway because AP signaling would likely be mixed, not-clean. > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) add/remove peer requests should be routed through master
[
https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747306#comment-15747306
]
Hadoop QA commented on HBASE-11392:
---
| (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 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 28s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 59s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 36s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 37s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 37s {color} |
{color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 37s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 10m
35s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s {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 15 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 15s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 29s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 42s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 56s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.4. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 9s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.5. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 23s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 43s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 56s
{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 11m 10s
{color} | {color:red} The patch causes 16 errors with Hadoop v3.0.0-alpha1.
{color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m 23s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 59s
{color} | {color:red} hbase-client generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 19s
{color} | {color:red} hbase-server in the patch failed. {color} |
|
[jira] [Commented] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747293#comment-15747293 ] Guanghao Zhang commented on HBASE-11392: Ok. Attach a patch only move add/remove peer requests to master admin api. Thanks. > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17296) Provide per peer throttling for replication
[ https://issues.apache.org/jira/browse/HBASE-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747276#comment-15747276 ] Guanghao Zhang commented on HBASE-17296: Thanks for reviewing. > Provide per peer throttling for replication > --- > > Key: HBASE-17296 > URL: https://issues.apache.org/jira/browse/HBASE-17296 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17296.patch > > > HBASE-9501 added a config to provide throttling for replication. And each > peer has same bandwidth up limit. In our use case, one cluster may have > several peers and several slave clusters. Each slave cluster may have > different scales and need different bandwidth up limit for each peer. So We > add bandwidth to replication peer config and provide a shell cmd set_peer > bandwidth to update the bandwidth in need. It has been used for a long time > on our clusters. Any suggestions are welcomed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17296) Provide per peer throttling for replication
[ https://issues.apache.org/jira/browse/HBASE-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747274#comment-15747274 ] Guanghao Zhang commented on HBASE-17296: Ok，upload patch for branch-1 later. > Provide per peer throttling for replication > --- > > Key: HBASE-17296 > URL: https://issues.apache.org/jira/browse/HBASE-17296 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17296.patch > > > HBASE-9501 added a config to provide throttling for replication. And each > peer has same bandwidth up limit. In our use case, one cluster may have > several peers and several slave clusters. Each slave cluster may have > different scales and need different bandwidth up limit for each peer. So We > add bandwidth to replication peer config and provide a shell cmd set_peer > bandwidth to update the bandwidth in need. It has been used for a long time > on our clusters. Any suggestions are welcomed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16033) Add more details in logging of responseTooSlow/TooLarge
[
https://issues.apache.org/jira/browse/HBASE-16033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747262#comment-15747262
]
Youngjoon Kim commented on HBASE-16033:
---
[~carp84] This and HBASE-16972 are marked as fixed on 1.2.4, but when using
1.2.4, I can see only old log format. Could you check that these are fixed on
1.2.4?
> Add more details in logging of responseTooSlow/TooLarge
> ---
>
> Key: HBASE-16033
> URL: https://issues.apache.org/jira/browse/HBASE-16033
> Project: HBase
> Issue Type: Improvement
> Components: Operability
>Affects Versions: 1.2.3, 1.1.7
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21, 1.2.4, 1.1.8
>
> Attachments: HBASE-16033.patch, HBASE-16033.patch, HBASE-16033.patch
>
>
> Currently the log message when responseTooSlow/TooLarge is like:
> {noformat}
> 2016-06-08 12:18:04,363 WARN
> [B.defaultRpcServer.handler=127,queue=10,port=16020]
> ipc.RpcServer: (responseTooSlow):
> {"processingtimems":13125,"call":"Multi(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$MultiRequest)",
> "client":"11.251.158.22:36331","starttimems":1465359471238,"queuetimems":1540116,
> "class":"HRegionServer","responsesize":17,"method":"Multi"}
> {noformat}
> which is kind of helpless for debugging since we don't know on which
> table/region/row the request is against.
> What's more, we could see some if-else check in the {{RpcServer#logResponse}}
> method which trying to do sth different when the {{param}} includes instance
> of {{Operation}}, but there's only one place invoking {{logResponse}} and the
> {{param}} is always an instance of {{Message}}. Checking the change history,
> I believe this is a left-over cleanup in work of HBASE-8214
> We will address the above issues, do some cleanup and improve the log just
> like {{RpcServer$Call#toString}} does to include table/region/row information
> of the request
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-16398) optimize HRegion computeHDFSBlocksDistribution
[
https://issues.apache.org/jira/browse/HBASE-16398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747228#comment-15747228
]
binlijin commented on HBASE-16398:
--
{quote}
Replace "hdfsblock dist" with HDFSBlocksDistribution
{quote}
Ok
{quote}
Shouldn't IOE be thrown for invalid store file ?
{quote}
No, this is no need. See the HRegionFileSystem#getStoreFiles(String familyName,
boolean validate) at
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionFileSystem.java#L212
{quote}
validStoreFiles is not returned. Is that intentional ?
{quote}
Good, it is a mistake, fix it in new patch.
> optimize HRegion computeHDFSBlocksDistribution
> --
>
> Key: HBASE-16398
> URL: https://issues.apache.org/jira/browse/HBASE-16398
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
> Fix For: 2.0.0
>
> Attachments: HBASE-16398.patch, HBASE-16398_v2.patch,
> HBASE-16398_v3.patch, HBASE-16398_v4.patch, HBASE-16398_v5.patch,
> LocatedBlockStatusComparison.java
>
>
> First i assume there is no reference and link in a region family's directory.
> Without the patch to computeHDFSBlocksDistribution for a region family, there
> is 1+2*N rpc call, N is hfile numbers, The first rpc call is to
> DistributedFileSystem#listStatus to get hfiles, for every hfile there is two
> rpc call DistributedFileSystem#getFileStatus(path) and then
> DistributedFileSystem#getFileBlockLocations(status, start, length).
> With the patch to computeHDFSBlocksDistribution for a region family, there is
> 2 rpc call, they are DistributedFileSystem#getFileStatus(path) and
> DistributedFileSystem#listLocatedStatus(final Path p, final PathFilter
> filter).
> So if there is at least one hfile, with the patch, the rpc call will less.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-16398) optimize HRegion computeHDFSBlocksDistribution
[ https://issues.apache.org/jira/browse/HBASE-16398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-16398: - Attachment: HBASE-16398_v5.patch > optimize HRegion computeHDFSBlocksDistribution > -- > > Key: HBASE-16398 > URL: https://issues.apache.org/jira/browse/HBASE-16398 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0 >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-16398.patch, HBASE-16398_v2.patch, > HBASE-16398_v3.patch, HBASE-16398_v4.patch, HBASE-16398_v5.patch, > LocatedBlockStatusComparison.java > > > First i assume there is no reference and link in a region family's directory. > Without the patch to computeHDFSBlocksDistribution for a region family, there > is 1+2*N rpc call, N is hfile numbers, The first rpc call is to > DistributedFileSystem#listStatus to get hfiles, for every hfile there is two > rpc call DistributedFileSystem#getFileStatus(path) and then > DistributedFileSystem#getFileBlockLocations(status, start, length). > With the patch to computeHDFSBlocksDistribution for a region family, there is > 2 rpc call, they are DistributedFileSystem#getFileStatus(path) and > DistributedFileSystem#listLocatedStatus(final Path p, final PathFilter > filter). > So if there is at least one hfile, with the patch, the rpc call will less. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2
[
https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747195#comment-15747195
]
Hadoop QA commented on HBASE-14123:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m 7s
{color} | {color:blue} Shelldocs was not available. {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 24 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 19s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 18s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
13s {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 48s
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 10s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 11s
{color} | {color:red} hbase-endpoint in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 2 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch 1 line(s) with tabs. {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}
23m 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} hbaseprotoc {color} | {color:green} 3m
39s {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:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 47s
{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} 3m 17s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 50s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 24s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} |
[jira] [Updated] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-11392: --- Attachment: HBASE-11392-v1.patch > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-11392: --- Assignee: Guanghao Zhang (was: Talat UYARER) Status: Patch Available (was: Open) > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Guanghao Zhang >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-11392-v1.patch > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16398) optimize HRegion computeHDFSBlocksDistribution
[
https://issues.apache.org/jira/browse/HBASE-16398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747183#comment-15747183
]
Ted Yu commented on HBASE-16398:
{code}
1180 // lets not create more objects here, not even another
hdfsblock dist
1181 FSUtils.addToHDFSBlocksDistribution(hdfsBlocksDistribution,
{code}
Replace "hdfsblock dist" with HDFSBlocksDistribution
{code}
245 if (validate && !StoreFileInfo.isValid(status)) {
246 LOG.warn("Invalid StoreFile: " + status.getPath());
{code}
Shouldn't IOE be thrown for invalid store file ?
{code}
248 validStoreFiles.add(status);
{code}
validStoreFiles is not returned. Is that intentional ?
> optimize HRegion computeHDFSBlocksDistribution
> --
>
> Key: HBASE-16398
> URL: https://issues.apache.org/jira/browse/HBASE-16398
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: binlijin
>Assignee: binlijin
> Fix For: 2.0.0
>
> Attachments: HBASE-16398.patch, HBASE-16398_v2.patch,
> HBASE-16398_v3.patch, HBASE-16398_v4.patch, LocatedBlockStatusComparison.java
>
>
> First i assume there is no reference and link in a region family's directory.
> Without the patch to computeHDFSBlocksDistribution for a region family, there
> is 1+2*N rpc call, N is hfile numbers, The first rpc call is to
> DistributedFileSystem#listStatus to get hfiles, for every hfile there is two
> rpc call DistributedFileSystem#getFileStatus(path) and then
> DistributedFileSystem#getFileBlockLocations(status, start, length).
> With the patch to computeHDFSBlocksDistribution for a region family, there is
> 2 rpc call, they are DistributedFileSystem#getFileStatus(path) and
> DistributedFileSystem#listLocatedStatus(final Path p, final PathFilter
> filter).
> So if there is at least one hfile, with the patch, the rpc call will less.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-11392) add/remove peer requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-11392: --- Summary: add/remove peer requests should be routed through master (was: Replication requests should be routed through master) > add/remove peer requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17296) Provide per peer throttling for replication
[ https://issues.apache.org/jira/browse/HBASE-17296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747169#comment-15747169 ] Phil Yang commented on HBASE-17296: --- [~zghaobac] Mind submit a patch for branch-1? Thanks. > Provide per peer throttling for replication > --- > > Key: HBASE-17296 > URL: https://issues.apache.org/jira/browse/HBASE-17296 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-17296.patch > > > HBASE-9501 added a config to provide throttling for replication. And each > peer has same bandwidth up limit. In our use case, one cluster may have > several peers and several slave clusters. Each slave cluster may have > different scales and need different bandwidth up limit for each peer. So We > add bandwidth to replication peer config and provide a shell cmd set_peer > bandwidth to update the bandwidth in need. It has been used for a long time > on our clusters. Any suggestions are welcomed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17138) Backport read-path offheap (HBASE-11425) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747155#comment-15747155 ] Yu Sun commented on HBASE-17138: [~tedyu] As you have listed, the backport needs lots of effort and i think it will need weeks to complete this. I am afraid I dont have enouth time to do this and cause the backport to be delayed. so if any others who have interesting in doing backport, I would like to provide any necessary help if needed. > Backport read-path offheap (HBASE-11425) to branch-1 > > > Key: HBASE-17138 > URL: https://issues.apache.org/jira/browse/HBASE-17138 > Project: HBase > Issue Type: Improvement >Reporter: Yu Li >Assignee: Yu Sun > Attachments: > 0001-fix-EHB-511-Resolve-client-compatibility-issue-introduced-by-offheap-change.patch, > 0001-to-EHB-446-offheap-hfile-format-should-keep-compatible-v3.patch, > 0001-to-EHB-456-Cell-should-be-compatible-with-branch-1.1.2.patch > > > From the > [thread|http://mail-archives.apache.org/mod_mbox/hbase-user/201611.mbox/%3CCAM7-19%2Bn7cEiY4H9iLQ3N9V0NXppOPduZwk-hhgNLEaJfiV3kA%40mail.gmail.com%3E] > of sharing our experience and performance data of read-path offheap usage in > Alibaba search, we could see people are positive to have HBASE-11425 in > branch-1, so I'd like to create a JIRA and move the discussion and decision > making here. > Echoing some comments from the mail thread: > Bryan: > Is the backported patch available anywhere? If it ends up not getting > officially backported to branch-1 due to 2.0 around the corner, some of us > who build our own deploy may want to integrate into our builds > Andrew: > Yes, please, the patches will be useful to the community even if we decide > not to backport into an official 1.x release. > Enis: > I don't see any reason why we cannot backport to branch-1. > Ted: > Opening a JIRA would be fine. This makes it easier for people to obtain the > patch(es) > Nick: > From the DISCUSS thread re: EOL of 1.1, it seems we'll continue to > support 1.x releases for some time... I would guess these will be > maintained until 2.2 at least. Therefore, offheap patches that have seen > production exposure seem like a reasonable candidate for backport, perhaps in > a 1.4 or 1.5 release timeframe. > Anoop: > Because of some compatibility issues, we decide that this will be done in 2.0 > only.. Ya as Andy said, it would be great to share the 1.x backported > patches. > The following is all the jira ids we have back ported: > HBASE-10930 Change Filters and GetClosestRowBeforeTracker to work with Cells > (Ram) > HBASE-13373 Squash HFileReaderV3 together with HFileReaderV2 and > AbstractHFileReader; ditto for Scanners and BlockReader, etc. > HBASE-13429 Remove deprecated seek/reseek methods from HFileScanner. > HBASE-13450 - Purge RawBytescomparator from the writers and readers for > HBASE-10800 (Ram) > HBASE-13501 - Deprecate/Remove getComparator() in HRegionInfo. > HBASE-12048 Remove deprecated APIs from Filter. > HBASE-10800 - Use CellComparator instead of KVComparator (Ram) > HBASE-13679 Change ColumnTracker and SQM to deal with Cell instead of byte[], > int, int. > HBASE-13642 Deprecate RegionObserver#postScannerFilterRow CP hook with > byte[],int,int args in favor of taking Cell arg. > HBASE-13641 Deperecate Filter#filterRowKey(byte[] buffer, int offset, int > length) in favor of filterRowKey(Cell firstRowCell). > HBASE-13827 Delayed scanner close in KeyValueHeap and StoreScanner. > HBASE-13871 Change RegionScannerImpl to deal with Cell instead of byte[], > int, int. > HBASE-11911 Break up tests into more fine grained categories (Alex Newman) > HBASE-12059 Create hbase-annotations module > HBASE-12106 Move test annotations to test artifact (Enis Soztutar) > HBASE-13916 Create MultiByteBuffer an aggregation of ByteBuffers. > HBASE-15679 Assertion on wrong variable in > TestReplicationThrottler#testThrottling > HBASE-13931 Move Unsafe based operations to UnsafeAccess. > HBASE-12345 Unsafe based ByteBuffer Comparator. > HBASE-13998 Remove CellComparator#compareRows(byte[] left, int loffset, int > llength, byte[] right, int roffset, int rlength). > HBASE-13998 Remove CellComparator#compareRows()- Addendum to fix javadoc warn > HBASE-13579 Avoid isCellTTLExpired() for NO-TAG cases (partially backport > this patch) > HBASE-13448 New Cell implementation with cached component offsets/lengths. > HBASE-13387 Add ByteBufferedCell an extension to Cell. > HBASE-13387 Add ByteBufferedCell an extension to Cell - addendum. > HBASE-12650 Move ServerName to hbase-common module (partially backport this > patch) > HBASE-12296 Filters should work with ByteBufferedCell. > HBASE-14120 ByteBufferUtils#compareTo small optimization. > HBASE-13510 - Purge ByteBloomFilter (Ram) > HBASE-13451 -
[jira] [Commented] (HBASE-17294) External Configuration for Memory Compaction
[
https://issues.apache.org/jira/browse/HBASE-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747149#comment-15747149
]
Hudson commented on HBASE-17294:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2128 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2128/])
HBASE-17294: External configuration for memory compaction (stack: rev
a9310436d51f40bae65d53db07c1ed2fb41d6348)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestPerColumnFamilyFlush.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactingMemStore.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMajorCompaction.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/AbstractTestLogRolling.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/TestAcidGuarantees.java
* (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestIOFencing.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSnapshotCloneIndependence.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRolling.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactingToCellArrayMapMemStore.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/AbstractTestWALReplay.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestAsyncLogRolling.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestWalAndCompactingMemStoreFlush.java
* (edit) hbase-shell/src/main/ruby/hbase/admin.rb
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestTableLockManager.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreCompactor.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestMobSnapshotFromClient.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRecoveredEdits.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/regionserver/TestCompactingMemStore.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/snapshot/TestFlushSnapshotFromClient.java
> External Configuration for Memory Compaction
> -
>
> Key: HBASE-17294
> URL: https://issues.apache.org/jira/browse/HBASE-17294
> Project: HBase
> Issue Type: Sub-task
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Fix For: 2.0.0
>
> Attachments: HBASE-17294-V01.patch, HBASE-17294-V02.patch,
> HBASE-17294-V03.patch
>
>
> We would like to have a single external knob to control memstore compaction.
> Possible memstore compaction policies are none, basic, and eager.
> This sub-task allows to set this property at the column family level at table
> creation time:
> {code}
> create ‘’,
>{NAME => ‘’,
> IN_MEMORY_COMPACTION => ‘’}
> {code}
> or to set this at the global configuration level by setting the property in
> hbase-site.xml, with BASIC being the default value:
> {code}
>
> hbase.hregion.compacting.memstore.type
>
>
> {code}
> The values used in this property can change as memstore compaction policies
> evolve over time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17309) Fix connection leaks in TestAcidGuarantees
[
https://issues.apache.org/jira/browse/HBASE-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747124#comment-15747124
]
Hadoop QA commented on HBASE-17309:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 26s
{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 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s {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} findbugs {color} | {color:green} 1m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {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}
26m 47s {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
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 108m 56s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 148m 45s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.2 Server=1.12.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843128/HBASE-17309-master-001.patch
|
| JIRA Issue | HBASE-17309 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 89bf5aabf9bf 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18
16:48:51 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 / de98f68 |
| Default Java | 1.8.0_111 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4901/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4901/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Fix connection leaks in TestAcidGuarantees
> --
>
> Key: HBASE-17309
> URL: https://issues.apache.org/jira/browse/HBASE-17309
> Project: HBase
> Issue Type: Bug
> Components: integration tests
>Affects Versions: 2.0.0
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Minor
> Attachments: HBASE-17309-master-001.patch
[jira] [Commented] (HBASE-17302) The region flush request disappeared from flushQueue
[
https://issues.apache.org/jira/browse/HBASE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747114#comment-15747114
]
Hudson commented on HBASE-17302:
FAILURE: Integrated in Jenkins build HBase-1.4 #565 (See
[https://builds.apache.org/job/HBase-1.4/565/])
HBASE-17302 The region flush request disappeared from flushQueue (tedyu: rev
e029c554bb70162b69c0992b93cbae581c7c7409)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java
> The region flush request disappeared from flushQueue
>
>
> Key: HBASE-17302
> URL: https://issues.apache.org/jira/browse/HBASE-17302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 0.98.23, 1.2.4
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17302-branch-1.2-v1.patch,
> HBASE-17302-branch-master-v1.patch
>
>
> Region has too many store files delaying flush up to blockingWaitTime ms, and
> the region flush request is requeued into the flushQueue.
> When the region flush request is requeued into the flushQueue frequently, the
> request is inexplicably disappeared sometimes.
> But regionsInQueue still contains the information of the region request,
> which leads to new flush request can not be inserted into the flushQueue.
> Then, the region will not do flush anymore.
> In order to locate the problem, I added a lot of log in the code.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> private boolean flushRegion(final HRegion region, final boolean
> emergencyFlush) {
> long startTime = 0;
> synchronized (this.regionsInQueue) {
> FlushRegionEntry fqe = this.regionsInQueue.remove(region);
> // Use the start time of the FlushRegionEntry if available
> if (fqe != null) {
> startTime = fqe.createTime;
> }
> if (fqe != null && emergencyFlush) {
> // Need to remove from region from delay queue. When NOT an
> // emergencyFlush, then item was removed via a flushQueue.poll.
> flushQueue.remove(fqe);
> }
> }
> {code}
> When encountered emergencyFlush, the region flusher will be removed from the
> flushQueue.
> By comparing the flushQueue content before and after remove, RegionA should
> have been removed, it is possible to remove RegionB.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null || getClass() != obj.getClass()) {
> return false;
> }
> Delayed other = (Delayed) obj;
> return compareTo(other) == 0;
> }
> {code}
> FlushRegionEntry in achieving the equals function, only comparison of the
> delay time, if different regions of the same delay time, it is possible that
> A wrong B.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17311) Refactoring: move backup system table out of 'hbase' namespace
[
https://issues.apache.org/jira/browse/HBASE-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747070#comment-15747070
]
Hadoop QA commented on HBASE-17311:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m 50s
{color} | {color:blue} Docker mode activated. {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} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 1s
{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:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m 54s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 45s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 39s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 31s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 23s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 13s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 4s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 54s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 44s
{color} | {color:red} Patch causes 16 errors with Hadoop v2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 23m 0s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:date2016-12-14 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843144/HBASE-17311.HBASE-7912.v1.patch
|
| JIRA Issue | HBASE-17311 |
| Optional Tests | hadoopcheck hbaseanti javac compile javadoc |
| uname | Linux e8313860c6c2 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18
21:21:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-7912 / 8d62d9a |
| Default Java | 1.7.0_121 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_111
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_121 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4903/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
>
[jira] [Updated] (HBASE-17311) Refactoring: move backup system table out of 'hbase' namespace
[ https://issues.apache.org/jira/browse/HBASE-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17311: -- Attachment: HBASE-17311.HBASE-7912.v1.patch Patch v1. cc: [~tedyu] > Refactoring: move backup system table out of 'hbase' namespace > -- > > Key: HBASE-17311 > URL: https://issues.apache.org/jira/browse/HBASE-17311 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-17311.HBASE-7912.v1.patch > > > In preparation to big refactoring (separate project for backup) we need to > move 'hbase:system' table out of HBase system namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17311) Refactoring: move backup system table out of 'hbase' namespace
[ https://issues.apache.org/jira/browse/HBASE-17311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17311: -- Status: Patch Available (was: Open) > Refactoring: move backup system table out of 'hbase' namespace > -- > > Key: HBASE-17311 > URL: https://issues.apache.org/jira/browse/HBASE-17311 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-17311.HBASE-7912.v1.patch > > > In preparation to big refactoring (separate project for backup) we need to > move 'hbase:system' table out of HBase system namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) Replication requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15747016#comment-15747016 ] Guanghao Zhang commented on HBASE-11392: bq. but if so I think we should do it for all or none to make it less confusing. Aggred. Open a new jdk8 issue HBASE-17312 for this. > Replication requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17312) [JDK8] Use default method in XXXObserver
[ https://issues.apache.org/jira/browse/HBASE-17312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17312: --- Issue Type: Sub-task (was: Task) Parent: HBASE-7608 > [JDK8] Use default method in XXXObserver > > > Key: HBASE-17312 > URL: https://issues.apache.org/jira/browse/HBASE-17312 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17312) [JDK8] Use default method in XXXObserver
Guanghao Zhang created HBASE-17312: -- Summary: [JDK8] Use default method in XXXObserver Key: HBASE-17312 URL: https://issues.apache.org/jira/browse/HBASE-17312 Project: HBase Issue Type: Task Components: Coprocessors Affects Versions: 2.0.0 Reporter: Guanghao Zhang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17262) Refactor RpcServer so as to make it extendable and/or pluggable
[ https://issues.apache.org/jira/browse/HBASE-17262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-17262: - Attachment: HBASE-17262.master.V2.patch > Refactor RpcServer so as to make it extendable and/or pluggable > --- > > Key: HBASE-17262 > URL: https://issues.apache.org/jira/browse/HBASE-17262 > Project: HBase > Issue Type: Sub-task > Components: Performance, rpc >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-17262.master.V1.patch, HBASE-17262.master.V2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-16398) optimize HRegion computeHDFSBlocksDistribution
[ https://issues.apache.org/jira/browse/HBASE-16398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746996#comment-15746996 ] binlijin commented on HBASE-16398: -- Ping [~te...@apache.org] [~thiruvel] [~enis] > optimize HRegion computeHDFSBlocksDistribution > -- > > Key: HBASE-16398 > URL: https://issues.apache.org/jira/browse/HBASE-16398 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0 >Reporter: binlijin >Assignee: binlijin > Fix For: 2.0.0 > > Attachments: HBASE-16398.patch, HBASE-16398_v2.patch, > HBASE-16398_v3.patch, HBASE-16398_v4.patch, LocatedBlockStatusComparison.java > > > First i assume there is no reference and link in a region family's directory. > Without the patch to computeHDFSBlocksDistribution for a region family, there > is 1+2*N rpc call, N is hfile numbers, The first rpc call is to > DistributedFileSystem#listStatus to get hfiles, for every hfile there is two > rpc call DistributedFileSystem#getFileStatus(path) and then > DistributedFileSystem#getFileBlockLocations(status, start, length). > With the patch to computeHDFSBlocksDistribution for a region family, there is > 2 rpc call, they are DistributedFileSystem#getFileStatus(path) and > DistributedFileSystem#listLocatedStatus(final Path p, final PathFilter > filter). > So if there is at least one hfile, with the patch, the rpc call will less. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) Replication requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746970#comment-15746970 ] Andrew Purtell commented on HBASE-11392: Current implementation defines interfaces (XXXObserver) and then abstract base classes (BaseXXXObserver) meant for consumption by implementors. We can change this to default methods but if so I think we should do it for all or none to make it less confusing. > Replication requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17310) Refactoring BackupAdmin: remove public access modifiers
[
https://issues.apache.org/jira/browse/HBASE-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746941#comment-15746941
]
Hadoop QA commented on HBASE-17310:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 19m 40s
{color} | {color:blue} Docker mode activated. {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} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
1s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 1s
{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 26s {color} | {color:green} 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} hbaseprotoc {color} | {color:green} 0m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 3s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 47m 35s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.2 Server=1.12.2 Image:yetus/hbase:date2016-12-14 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843134/HBASE-17310.HBASE-7912.v1.patch
|
| JIRA Issue | HBASE-17310 |
| Optional Tests | hadoopcheck hbaseanti javac compile javadoc |
| uname | Linux b2b7261a650b 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18
16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-7912 / 8d62d9a |
| Default Java | 1.7.0_121 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_111
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_121 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4902/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Refactoring BackupAdmin: remove public access modifiers
> ---
>
> Key: HBASE-17310
> URL: https://issues.apache.org/jira/browse/HBASE-17310
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Trivial
> Attachments: HBASE-17310.HBASE-7912.v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17308) BackupInfo getShortDescription output format
[
https://issues.apache.org/jira/browse/HBASE-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746892#comment-15746892
]
Hadoop QA commented on HBASE-17308:
---
| (/) *{color:green}+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} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
1s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} HBASE-7912 passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 1s
{color} | {color:green} HBASE-7912 passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 1s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 1s
{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 21s {color} | {color:green} 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} hbaseprotoc {color} | {color:green} 0m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.8.0_111 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 2s
{color} | {color:green} the patch passed with JDK v1.7.0_121 {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 25m 57s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:date2016-12-14 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843126/HBASE-17308.HBASE-7912.v1.patch
|
| JIRA Issue | HBASE-17308 |
| Optional Tests | hadoopcheck hbaseanti javac compile javadoc |
| uname | Linux 04e9dc1c85d4 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 | nobuild |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-7912 / 8d62d9a |
| Default Java | 1.7.0_121 |
| Multi-JDK versions | /usr/lib/jvm/java-8-oracle:1.8.0_111
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_121 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4900/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> BackupInfo getShortDescription output format
>
>
> Key: HBASE-17308
> URL: https://issues.apache.org/jira/browse/HBASE-17308
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Trivial
> Attachments: HBASE-17308.HBASE-7912.v1.patch
>
>
> Currently its multiline and is hard to parse, convert it to a single line
> output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746879#comment-15746879 ] Joep Rottinghuis commented on HBASE-17018: -- Interesting idea about using attributes on the mutation itself. That wouldn't mess with the way the BufferedMutatorImpl would deal with them? I don't want those attributes to be transmitted to HBase, that would be a waste. I'll read up more, but upon first inspection I should be able to stash flushCount, submit- and completion times in a byte[]. Putting a flushLatch there would be harder. I'd have to think if that can be stashed and communicated in a different way. The other impact is that I'd have to peel apart a list of mutations and set attributes on each. Right now a submission maintains a List of Mutations so that they can be added to BufferedMutatorImpl in batch. bq. This will not be committed to hbase? It'll be part of timeline v2? Is that a question or statement? ;) If the HBase community is interested to have this part of HBase, that would be great and I'll continue the code in place. If not, then I'll move this to yarn. bq. The bulk of the change in BufferedMutatorParams is unrelated. You want to do a patch w/ just the changes to hbase core removing the non-changes: i.e. in BufferedMutatorParams only change should be the clone method addition, not the reformatting of javadoc. Reformatting javadoc wasn't intended. I'll remove that. In fact, I'll file a separate sub-jira to just add the clone method to the BufferedMutatorParams to separate out that concern. bq. Is FilesystemMutationSpooler still TODO? Is it needed? There doesn't seem to be much filesystem-ey about FilesystemMutationSpooler, at least just yet. Indeed this is still completely an empty template. Actual implementation still open. I didn't want to go too far with implementation, just sketch out enough to make the design clear to get feedback on that. I started with the diagram and a description, but as I was thinking through more details the design had to be tweaked. I figured POC code would do best job in describing the design. With respect to public boolean shouldSpool() indeed, the code right now it a bit more verbose than needed. I'll collapse to the simple format if indeed I don't need to keep track of the max successful flushCount. I need to add actual tests before I can get those details added. bq. If SpoolingBufferedMutatorCoordinator Interface a bit over the top? Is there ever going to be another type of cooridinator implementation? Yes indeed and no probably not. I started with this thinking I needed to make it pluggable for testing. But you're right that no interface is needed there, I can simply use inheritance and still control tests. bq. Otherwise skimmed the rest.. Where are the tests? Tests are still missing indeed. Just a design sketch at the moment. If the approach seems sane, I'll add unit tests. Thanks for the feedback [~stack] > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17305) Two active HBase Masters can run at the same time under certain circumstances
[ https://issues.apache.org/jira/browse/HBASE-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746867#comment-15746867 ] Enis Soztutar commented on HBASE-17305: --- This is interesting. Did the previous active master lose the zookeeper connection, and reconnected? Or it is restarted? > Two active HBase Masters can run at the same time under certain circumstances > -- > > Key: HBASE-17305 > URL: https://issues.apache.org/jira/browse/HBASE-17305 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 2.0.0 >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez >Priority: Critical > > This needs a little more investigation, but we found a very edgy case when > the active master is restarted and a stand-by master tries to become active, > however the original active master was able to become the active master again > and just before the standby master passed the point of the transition to > become active we ended up with two active masters running at the same time. > Assuming the clock on both masters were accurate to milliseconds, this race > happened in less than 85ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11392) Replication requests should be routed through master
[ https://issues.apache.org/jira/browse/HBASE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746858#comment-15746858 ] Guanghao Zhang commented on HBASE-11392: Thanks for pointed out this. I thought the new master replication admin APIs will only be added to 2.0 which only support java 8. So for compatibility issue, the new APIs in coprocessor should use default method? > Replication requests should be routed through master > > > Key: HBASE-11392 > URL: https://issues.apache.org/jira/browse/HBASE-11392 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Talat UYARER >Priority: Critical > Fix For: 2.0.0 > > > ReplicationAdmin directly operates over the zookeeper data for replication > setup. We should move these operations to be routed through master for two > reasons: > - Replication implementation details are exposed to client. We should move > most of the replication related classes to hbase-server package. > - Routing the requests through master is the standard practice for all other > operations. It allows for decoupling implementation details from the client > and code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17294) External Configuration for Memory Compaction
[
https://issues.apache.org/jira/browse/HBASE-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-17294:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
Status: Resolved (was: Patch Available)
Pushed to master branch. Thanks for the patch [~eshcar] Mind adding a release
note please (copy paste your javadoc on options?) Thanks.
> External Configuration for Memory Compaction
> -
>
> Key: HBASE-17294
> URL: https://issues.apache.org/jira/browse/HBASE-17294
> Project: HBase
> Issue Type: Sub-task
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Fix For: 2.0.0
>
> Attachments: HBASE-17294-V01.patch, HBASE-17294-V02.patch,
> HBASE-17294-V03.patch
>
>
> We would like to have a single external knob to control memstore compaction.
> Possible memstore compaction policies are none, basic, and eager.
> This sub-task allows to set this property at the column family level at table
> creation time:
> {code}
> create ‘’,
>{NAME => ‘’,
> IN_MEMORY_COMPACTION => ‘’}
> {code}
> or to set this at the global configuration level by setting the property in
> hbase-site.xml, with BASIC being the default value:
> {code}
>
> hbase.hregion.compacting.memstore.type
>
>
> {code}
> The values used in this property can change as memstore compaction policies
> evolve over time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-17311) Refactoring: move backup system table out of 'hbase' namespace
Vladimir Rodionov created HBASE-17311: - Summary: Refactoring: move backup system table out of 'hbase' namespace Key: HBASE-17311 URL: https://issues.apache.org/jira/browse/HBASE-17311 Project: HBase Issue Type: Bug Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov In preparation to big refactoring (separate project for backup) we need to move 'hbase:system' table out of HBase system namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17310) Refactoring BackupAdmin: remove public access modifiers
[ https://issues.apache.org/jira/browse/HBASE-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17310: -- Attachment: HBASE-17310.HBASE-7912.v1.patch patch v1. cc: [~tedyu] > Refactoring BackupAdmin: remove public access modifiers > --- > > Key: HBASE-17310 > URL: https://issues.apache.org/jira/browse/HBASE-17310 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Trivial > Attachments: HBASE-17310.HBASE-7912.v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17294) External Configuration for Memory Compaction
[
https://issues.apache.org/jira/browse/HBASE-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746829#comment-15746829
]
Hadoop QA commented on HBASE-17294:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s
{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} 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 20 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 16s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 0s
{color} | {color:green} master passed {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} 1m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 19s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s {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}
28m 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} findbugs {color} | {color:green} 2m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 54s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 96m 36s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 31s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 154m 21s {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/12843103/HBASE-17294-V03.patch
|
| JIRA Issue | HBASE-17294 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile rubocop ruby_lint |
| uname | Linux 7d8fff433fca 3.13.0-93-generic #140-Ubuntu SMP Mon Jul 18
21:21:05 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 /
[jira] [Updated] (HBASE-17310) Refactoring BackupAdmin: remove public access modifiers
[ https://issues.apache.org/jira/browse/HBASE-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17310: -- Status: Patch Available (was: Open) > Refactoring BackupAdmin: remove public access modifiers > --- > > Key: HBASE-17310 > URL: https://issues.apache.org/jira/browse/HBASE-17310 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Trivial > Attachments: HBASE-17310.HBASE-7912.v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17310) Refactoring BackupAdmin: remove public access modifiers
Vladimir Rodionov created HBASE-17310: - Summary: Refactoring BackupAdmin: remove public access modifiers Key: HBASE-17310 URL: https://issues.apache.org/jira/browse/HBASE-17310 Project: HBase Issue Type: Bug Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Priority: Trivial -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-17303) Let master to check and transfer the dead rs's replication queues
[
https://issues.apache.org/jira/browse/HBASE-17303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reassigned HBASE-17303:
--
Assignee: Guanghao Zhang
> Let master to check and transfer the dead rs's replication queues
> -
>
> Key: HBASE-17303
> URL: https://issues.apache.org/jira/browse/HBASE-17303
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>
> Dump replication queues result from our cluster.
> {code}
> Found 8 deleted queues, run hbck -fixReplication in order to remove the
> deleted replication queues
> hostname,24610,1481528189915/80-hostname,24620,1476784763605
>
> hostname,24620,1476784763605/70-hostname,24630,1470418208092-hostname,24600,1476773709589
>
> hostname,24630,1481528526258/17000-hostname,24620,1470044455538-hostname,24630,1470037674231-hostname,24600,1476773708489-hostname,24620,1476784763605
>
> hostname,24620,1481528358531/70-hostname,24600,1476773709589-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/70-hostname,24630,1470421093464-hostname,24630,1476773708939-hostname,24610,1476779010928-hostname,24620,1476784747260
> hostname,24600,1481528021595/17000-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/17000-hostname,24630,1475381530644-hostname,24600,1476773709589-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/17000-hostname,24600,1476773709589-hostname,24620,1476784763605
> Found 2 dead regionservers, restart one regionserver to transfer the queues
> of dead regionservers
> hostname,24600,1481547616148
> hostname,24620,1476784763605
> {code}
> Now for dead rs's replication znode, you need restart one regionserver to
> transfer the replication queues of dead regionservers. Same idea with
> HBASE-16336, we can let master to periodically check the dead rs znode, too.
> And send the transfer replication queues request to any regionserver. Then
> the dead rs's replication queues can be transfer automatically and don't need
> to wait a regionserver restart. Any suggestions are welcomed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17018) Spooling BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746798#comment-15746798
]
stack commented on HBASE-17018:
---
Nice writeup/design. Looks good. Like the tracking of 'batches'. There seems to
be a bunch of moving parts but all seem necessary.
On "...wrapped in a SpoolingBufferedMutatorSubmission which comes in three
SpoolingBufferedMutatorSubmissionType...", if you were looking for a simpler
approach, you might just add markers to the Mutation Map of Attributes...
https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/OperationWithAttributes.html#setAttribute-java.lang.String-byte:A-
On the patch:
This will not be committed to hbase? It'll be part of timeline v2? (Or
looking at the patch, there is some change needed in core ... in
BufferedMutatorParams... these we can take).
The bulk of the change in BufferedMutatorParams is unrelated. You want to do a
patch w/ just the changes to hbase core removing the non-changes: i.e. in
BufferedMutatorParams only change should be the clone method addition, not the
reformatting of javadoc.
Is FilesystemMutationSpooler still TODO? Is it needed? There doesn't seem to be
much filesystem-ey about FilesystemMutationSpooler, at least just yet.
If SpoolingBufferedMutatorCoordinator Interface a bit over the top? Is there
ever going to be another type of cooridinator implementation?
nit: Could change this
145 public boolean shouldSpool(SpoolingBufferedMutatorSubmission
submission) {
146 // TODO: should we keep track of the last successful flush that
went through
147 // and perhaps still drop some items from outbound, even if we just
went
148 // into a bad state?
149 if (state == State.GOOD) {
150 return false;
151 } else {
152 // Spool for both BAD and TRANSITIONING states.
153 return true;
154 }
155 }
to
return state != State.GOOD;
Otherwise skimmed the rest.. Where are the tests?
Looks good [~jrottinghuis]
> Spooling BufferedMutator
>
>
> Key: HBASE-17018
> URL: https://issues.apache.org/jira/browse/HBASE-17018
> Project: HBase
> Issue Type: New Feature
>Reporter: Joep Rottinghuis
> Attachments: HBASE-17018.master.001.patch,
> HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements
> for fault tolerant writer.pdf
>
>
> For Yarn Timeline Service v2 we use HBase as a backing store.
> A big concern we would like to address is what to do if HBase is
> (temporarily) down, for example in case of an HBase upgrade.
> Most of the high volume writes will be mostly on a best-effort basis, but
> occasionally we do a flush. Mainly during application lifecycle events,
> clients will call a flush on the timeline service API. In order to handle the
> volume of writes we use a BufferedMutator. When flush gets called on our API,
> we in turn call flush on the BufferedMutator.
> We would like our interface to HBase be able to spool the mutations to a
> filesystems in case of HBase errors. If we use the Hadoop filesystem
> interface, this can then be HDFS, gcs, s3, or any other distributed storage.
> The mutations can then later be re-played, for example through a MapReduce
> job.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17302) The region flush request disappeared from flushQueue
[
https://issues.apache.org/jira/browse/HBASE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746764#comment-15746764
]
Hudson commented on HBASE-17302:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2127 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/2127/])
HBASE-17302 The region flush request disappeared from flushQueue (tedyu: rev
de98f684086bc33b418d530c2473902a97fbc7cc)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java
> The region flush request disappeared from flushQueue
>
>
> Key: HBASE-17302
> URL: https://issues.apache.org/jira/browse/HBASE-17302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 0.98.23, 1.2.4
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17302-branch-1.2-v1.patch,
> HBASE-17302-branch-master-v1.patch
>
>
> Region has too many store files delaying flush up to blockingWaitTime ms, and
> the region flush request is requeued into the flushQueue.
> When the region flush request is requeued into the flushQueue frequently, the
> request is inexplicably disappeared sometimes.
> But regionsInQueue still contains the information of the region request,
> which leads to new flush request can not be inserted into the flushQueue.
> Then, the region will not do flush anymore.
> In order to locate the problem, I added a lot of log in the code.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> private boolean flushRegion(final HRegion region, final boolean
> emergencyFlush) {
> long startTime = 0;
> synchronized (this.regionsInQueue) {
> FlushRegionEntry fqe = this.regionsInQueue.remove(region);
> // Use the start time of the FlushRegionEntry if available
> if (fqe != null) {
> startTime = fqe.createTime;
> }
> if (fqe != null && emergencyFlush) {
> // Need to remove from region from delay queue. When NOT an
> // emergencyFlush, then item was removed via a flushQueue.poll.
> flushQueue.remove(fqe);
> }
> }
> {code}
> When encountered emergencyFlush, the region flusher will be removed from the
> flushQueue.
> By comparing the flushQueue content before and after remove, RegionA should
> have been removed, it is possible to remove RegionB.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null || getClass() != obj.getClass()) {
> return false;
> }
> Delayed other = (Delayed) obj;
> return compareTo(other) == 0;
> }
> {code}
> FlushRegionEntry in achieving the equals function, only comparison of the
> delay time, if different regions of the same delay time, it is possible that
> A wrong B.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17309) Fix connection leaks in TestAcidGuarantees
[ https://issues.apache.org/jira/browse/HBASE-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-17309: - Attachment: HBASE-17309-master-001.patch > Fix connection leaks in TestAcidGuarantees > -- > > Key: HBASE-17309 > URL: https://issues.apache.org/jira/browse/HBASE-17309 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > Attachments: HBASE-17309-master-001.patch > > > Connections are not closed in some of TestAcidGuarantees's classes, this > makes integration test fail in some cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17309) Fix connection leaks in TestAcidGuarantees
[ https://issues.apache.org/jira/browse/HBASE-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-17309: - Status: Patch Available (was: Open) > Fix connection leaks in TestAcidGuarantees > -- > > Key: HBASE-17309 > URL: https://issues.apache.org/jira/browse/HBASE-17309 > Project: HBase > Issue Type: Bug > Components: integration tests >Affects Versions: 2.0.0 >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > Attachments: HBASE-17309-master-001.patch > > > Connections are not closed in some of TestAcidGuarantees's classes, this > makes integration test fail in some cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17309) Fix connection leaks in TestAcidGuarantees
huaxiang sun created HBASE-17309: Summary: Fix connection leaks in TestAcidGuarantees Key: HBASE-17309 URL: https://issues.apache.org/jira/browse/HBASE-17309 Project: HBase Issue Type: Bug Components: integration tests Affects Versions: 2.0.0 Reporter: huaxiang sun Assignee: huaxiang sun Priority: Minor Connections are not closed in some of TestAcidGuarantees's classes, this makes integration test fail in some cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17307) Fix pom.xml (distcp version)
[
https://issues.apache.org/jira/browse/HBASE-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746721#comment-15746721
]
Hadoop QA commented on HBASE-17307:
---
| (/) *{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} hbaseprotoc {color} | {color:green} 0m
1s {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 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 8s {color} | {color:green} 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} hbaseprotoc {color} | {color:green} 0m
2s {color} | {color:green} the patch passed {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 23m 29s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:date2016-12-14 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843125/HBASE-17307.HBASE-7912.v1.patch
|
| JIRA Issue | HBASE-17307 |
| Optional Tests | xml |
| uname | Linux 0dcc9d175fcb 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 | nobuild |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-7912 / 8d62d9a |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4899/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Fix pom.xml (distcp version)
>
>
> Key: HBASE-17307
> URL: https://issues.apache.org/jira/browse/HBASE-17307
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17307.HBASE-7912.v1.patch
>
>
> Currently, hbase-server/pom.xml has hardcoded version for distcp package,
> which is hadoop-two.version. This won't work for hadoop-three.version profile.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17025) [Shell] Support space quota get/set via the shell
[
https://issues.apache.org/jira/browse/HBASE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746717#comment-15746717
]
Hadoop QA commented on HBASE-17025:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 32m 20s
{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: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} 5m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {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: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}
39m 5s {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 17s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 25s {color}
| {color:red} hbase-shell 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} 80m 54s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestReplicationShell |
| | hadoop.hbase.client.TestShell |
| | hadoop.hbase.client.TestShellNoCluster |
| | hadoop.hbase.client.rsgroup.TestShellRSGroups |
\\
\\
|| 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/12841844/HBASE-17025.001.patch
|
| JIRA Issue | HBASE-17025 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 9686173f6007 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 / de98f68 |
| Default Java | 1.8.0_111 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/4897/artifact/patchprocess/patch-unit-hbase-shell.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/4897/artifact/patchprocess/patch-unit-hbase-shell.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/4897/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4897/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> [Shell] Support space quota get/set via the shell
> -
>
> Key: HBASE-17025
> URL: https://issues.apache.org/jira/browse/HBASE-17025
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0
>
> Attachments: HBASE-17025.001.patch
>
>
> Need to make sure that admins can use the shell to get/set the new space
> quotas.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17308) BackupInfo getShortDescription output format
[ https://issues.apache.org/jira/browse/HBASE-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17308: -- Attachment: HBASE-17308.HBASE-7912.v1.patch patch v1. cc :[~tedyu] > BackupInfo getShortDescription output format > > > Key: HBASE-17308 > URL: https://issues.apache.org/jira/browse/HBASE-17308 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Trivial > Attachments: HBASE-17308.HBASE-7912.v1.patch > > > Currently its multiline and is hard to parse, convert it to a single line > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17308) BackupInfo getShortDescription output format
[ https://issues.apache.org/jira/browse/HBASE-17308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17308: -- Status: Patch Available (was: Open) > BackupInfo getShortDescription output format > > > Key: HBASE-17308 > URL: https://issues.apache.org/jira/browse/HBASE-17308 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Trivial > Attachments: HBASE-17308.HBASE-7912.v1.patch > > > Currently its multiline and is hard to parse, convert it to a single line > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17308) BackupInfo getShortDescription output format
Vladimir Rodionov created HBASE-17308: - Summary: BackupInfo getShortDescription output format Key: HBASE-17308 URL: https://issues.apache.org/jira/browse/HBASE-17308 Project: HBase Issue Type: Bug Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Priority: Trivial Currently its multiline and is hard to parse, convert it to a single line output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17307) Fix pom.xml (distcp version)
[ https://issues.apache.org/jira/browse/HBASE-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17307: -- Fix Version/s: 2.0.0 > Fix pom.xml (distcp version) > > > Key: HBASE-17307 > URL: https://issues.apache.org/jira/browse/HBASE-17307 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17307.HBASE-7912.v1.patch > > > Currently, hbase-server/pom.xml has hardcoded version for distcp package, > which is hadoop-two.version. This won't work for hadoop-three.version profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17307) Fix pom.xml (distcp version)
[ https://issues.apache.org/jira/browse/HBASE-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17307: -- Status: Patch Available (was: Open) > Fix pom.xml (distcp version) > > > Key: HBASE-17307 > URL: https://issues.apache.org/jira/browse/HBASE-17307 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Attachments: HBASE-17307.HBASE-7912.v1.patch > > > Currently, hbase-server/pom.xml has hardcoded version for distcp package, > which is hadoop-two.version. This won't work for hadoop-three.version profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17307) Fix pom.xml (distcp version)
[ https://issues.apache.org/jira/browse/HBASE-17307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17307: -- Attachment: HBASE-17307.HBASE-7912.v1.patch Patch v1. cc: [~tedyu] > Fix pom.xml (distcp version) > > > Key: HBASE-17307 > URL: https://issues.apache.org/jira/browse/HBASE-17307 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Attachments: HBASE-17307.HBASE-7912.v1.patch > > > Currently, hbase-server/pom.xml has hardcoded version for distcp package, > which is hadoop-two.version. This won't work for hadoop-three.version profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-17307) Fix pom.xml (distcp version)
Vladimir Rodionov created HBASE-17307: - Summary: Fix pom.xml (distcp version) Key: HBASE-17307 URL: https://issues.apache.org/jira/browse/HBASE-17307 Project: HBase Issue Type: Bug Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Priority: Minor Currently, hbase-server/pom.xml has hardcoded version for distcp package, which is hadoop-two.version. This won't work for hadoop-three.version profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746629#comment-15746629 ] Vladimir Rodionov commented on HBASE-14123: --- [~Stack], I posted patch v42 (and change list) on RB. It is ready for review. > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Fix For: 2.0.0 > > Attachments: 14123-master.v14.txt, 14123-master.v15.txt, > 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, > 14123-master.v19.txt, 14123-master.v2.txt, 14123-master.v20.txt, > 14123-master.v21.txt, 14123-master.v24.txt, 14123-master.v25.txt, > 14123-master.v27.txt, 14123-master.v28.txt, 14123-master.v29.full.txt, > 14123-master.v3.txt, 14123-master.v30.txt, 14123-master.v31.txt, > 14123-master.v32.txt, 14123-master.v33.txt, 14123-master.v34.txt, > 14123-master.v35.txt, 14123-master.v36.txt, 14123-master.v37.txt, > 14123-master.v38.txt, 14123-master.v5.txt, 14123-master.v6.txt, > 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, > 14123.master.v39.patch, 14123.master.v40.patch, 14123.master.v41.patch, > 14123.master.v42.patch, HBASE-14123-for-7912-v1.patch, > HBASE-14123-for-7912-v6.patch, HBASE-14123-v1.patch, HBASE-14123-v10.patch, > HBASE-14123-v11.patch, HBASE-14123-v12.patch, HBASE-14123-v13.patch, > HBASE-14123-v15.patch, HBASE-14123-v16.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch, HBASE-14123-v9.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14123) HBase Backup/Restore Phase 2
[ https://issues.apache.org/jira/browse/HBASE-14123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14123: -- Attachment: 14123.master.v42.patch Patch v42: # Moved backup system table out of HBase system namespace # Reverted all non-backup related unit tests (reduce patch size by 55KB) # Fixed pom.xml (distcp version) # BackupInfo.getShortDescription() now is one line # Removed public access modifiers from BackupAdmin cc: [~saint@gmail.com] > HBase Backup/Restore Phase 2 > > > Key: HBASE-14123 > URL: https://issues.apache.org/jira/browse/HBASE-14123 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Fix For: 2.0.0 > > Attachments: 14123-master.v14.txt, 14123-master.v15.txt, > 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, > 14123-master.v19.txt, 14123-master.v2.txt, 14123-master.v20.txt, > 14123-master.v21.txt, 14123-master.v24.txt, 14123-master.v25.txt, > 14123-master.v27.txt, 14123-master.v28.txt, 14123-master.v29.full.txt, > 14123-master.v3.txt, 14123-master.v30.txt, 14123-master.v31.txt, > 14123-master.v32.txt, 14123-master.v33.txt, 14123-master.v34.txt, > 14123-master.v35.txt, 14123-master.v36.txt, 14123-master.v37.txt, > 14123-master.v38.txt, 14123-master.v5.txt, 14123-master.v6.txt, > 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, > 14123.master.v39.patch, 14123.master.v40.patch, 14123.master.v41.patch, > 14123.master.v42.patch, HBASE-14123-for-7912-v1.patch, > HBASE-14123-for-7912-v6.patch, HBASE-14123-v1.patch, HBASE-14123-v10.patch, > HBASE-14123-v11.patch, HBASE-14123-v12.patch, HBASE-14123-v13.patch, > HBASE-14123-v15.patch, HBASE-14123-v16.patch, HBASE-14123-v2.patch, > HBASE-14123-v3.patch, HBASE-14123-v4.patch, HBASE-14123-v5.patch, > HBASE-14123-v6.patch, HBASE-14123-v7.patch, HBASE-14123-v9.patch > > > Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17000) [RegionServer] Compute region filesystem space use and report to Master
[
https://issues.apache.org/jira/browse/HBASE-17000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746573#comment-15746573
]
Hadoop QA commented on HBASE-17000:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 24s
{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 3 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 4m 29s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
30s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s
{color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
34s {color} | {color:green} HBASE-16961 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
9s {color} | {color:green} HBASE-16961 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 5s
{color} | {color:red} hbase-protocol-shaded in HBASE-16961 has 24 extant
Findbugs warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} HBASE-16961 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {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 11 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 9s
{color} | {color:red} The patch causes 270 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 15s
{color} | {color:red} The patch causes 270 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 24s
{color} | {color:red} The patch causes 270 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 33s
{color} | {color:red} The patch causes 270 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 42s
{color} | {color:red} The patch causes 270 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m 24s
{color} | {color:red} Patch generated 1 new protoc errors in hbase-server.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 29s
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 95m 16s
{color} | {color:green} hbase-server in the patch passed. {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} 175m 57s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch
[jira] [Updated] (HBASE-17018) Spooling BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-17018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joep Rottinghuis updated HBASE-17018: - Attachment: HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf HBASE-17018.master.001.patch Based on feedback, I've attached a new design doc. This is the shared Google doc open for comments: https://docs.google.com/document/d/1GTSk1Hd887gGJduUr8ZJ2m-VKrIXDUv9K3dr4u2YGls/edit?usp=sharing I've attached a sketch of what the code would look like (HBASE-17018.master.001.patch) to clarify what this design in a bit more details than is worded in the doc. It is ready for design feedback, not for code feedback. It has tons of TODOs and open items and is lacking any unit tests. If people think this is a sensible approach I can work out the code to more details with unit tests, and a POC for the spooling code. > Spooling BufferedMutator > > > Key: HBASE-17018 > URL: https://issues.apache.org/jira/browse/HBASE-17018 > Project: HBase > Issue Type: New Feature >Reporter: Joep Rottinghuis > Attachments: HBASE-17018.master.001.patch, > HBASE-17018SpoolingBufferedMutatorDesign-v1.pdf, YARN-4061 HBase requirements > for fault tolerant writer.pdf > > > For Yarn Timeline Service v2 we use HBase as a backing store. > A big concern we would like to address is what to do if HBase is > (temporarily) down, for example in case of an HBase upgrade. > Most of the high volume writes will be mostly on a best-effort basis, but > occasionally we do a flush. Mainly during application lifecycle events, > clients will call a flush on the timeline service API. In order to handle the > volume of writes we use a BufferedMutator. When flush gets called on our API, > we in turn call flush on the BufferedMutator. > We would like our interface to HBase be able to spool the mutations to a > filesystems in case of HBase errors. If we use the Hadoop filesystem > interface, this can then be HDFS, gcs, s3, or any other distributed storage. > The mutations can then later be re-played, for example through a MapReduce > job. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17259) Missing functionality to remove space quota
[
https://issues.apache.org/jira/browse/HBASE-17259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746538#comment-15746538
]
Hadoop QA commented on HBASE-17259:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s {color}
| {color:red} HBASE-17259 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12841826/HBASE-17259.001.patch
|
| JIRA Issue | HBASE-17259 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4895/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Missing functionality to remove space quota
> ---
>
> Key: HBASE-17259
> URL: https://issues.apache.org/jira/browse/HBASE-17259
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0
>
> Attachments: HBASE-17259.001.patch
>
>
> I'm noticing that while I have create and update APIs for quotas, I missed
> the remove functionality.
> Need to add public API for that and some tests.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17001) [RegionServer] Implement enforcement of quota violation policies
[
https://issues.apache.org/jira/browse/HBASE-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746539#comment-15746539
]
Hadoop QA commented on HBASE-17001:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s {color}
| {color:red} HBASE-17001 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12843113/HBASE-17001.001.patch
|
| JIRA Issue | HBASE-17001 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/4896/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> [RegionServer] Implement enforcement of quota violation policies
>
>
> Key: HBASE-17001
> URL: https://issues.apache.org/jira/browse/HBASE-17001
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0
>
> Attachments: HBASE-17001.001.patch
>
>
> When the master enacts a quota violation policy, the RegionServers need to
> actually enforce that policy per its definition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17259) Missing functionality to remove space quota
[ https://issues.apache.org/jira/browse/HBASE-17259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17259: --- Status: Patch Available (was: Open) > Missing functionality to remove space quota > --- > > Key: HBASE-17259 > URL: https://issues.apache.org/jira/browse/HBASE-17259 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-17259.001.patch > > > I'm noticing that while I have create and update APIs for quotas, I missed > the remove functionality. > Need to add public API for that and some tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17025) [Shell] Support space quota get/set via the shell
[ https://issues.apache.org/jira/browse/HBASE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17025: --- Fix Version/s: 2.0.0 > [Shell] Support space quota get/set via the shell > - > > Key: HBASE-17025 > URL: https://issues.apache.org/jira/browse/HBASE-17025 > Project: HBase > Issue Type: Sub-task > Components: shell >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-17025.001.patch > > > Need to make sure that admins can use the shell to get/set the new space > quotas. -- 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.001.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_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-17025) [Shell] Support space quota get/set via the shell
[ https://issues.apache.org/jira/browse/HBASE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17025: --- Status: Patch Available (was: Open) > [Shell] Support space quota get/set via the shell > - > > Key: HBASE-17025 > URL: https://issues.apache.org/jira/browse/HBASE-17025 > Project: HBase > Issue Type: Sub-task > Components: shell >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-17025.001.patch > > > Need to make sure that admins can use the shell to get/set the new space > quotas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17001) [RegionServer] Implement enforcement of quota violation policies
[ https://issues.apache.org/jira/browse/HBASE-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17001: --- Status: Patch Available (was: Open) > [RegionServer] Implement enforcement of quota violation policies > > > Key: HBASE-17001 > URL: https://issues.apache.org/jira/browse/HBASE-17001 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-17001.001.patch > > > When the master enacts a quota violation policy, the RegionServers need to > actually enforce that policy per its definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17001) [RegionServer] Implement enforcement of quota violation policies
[ https://issues.apache.org/jira/browse/HBASE-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17001: --- Attachment: HBASE-17001.001.patch .001 Parking this one while the reviews catch up. This is the "exciting" patch that actually shows some end-to-end space quota functionality. > [RegionServer] Implement enforcement of quota violation policies > > > Key: HBASE-17001 > URL: https://issues.apache.org/jira/browse/HBASE-17001 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-17001.001.patch > > > When the master enacts a quota violation policy, the RegionServers need to > actually enforce that policy per its definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17294) External Configuration for Memory Compaction
[
https://issues.apache.org/jira/browse/HBASE-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746517#comment-15746517
]
stack commented on HBASE-17294:
---
+1 Waiting on hadoopqa before commit.
> External Configuration for Memory Compaction
> -
>
> Key: HBASE-17294
> URL: https://issues.apache.org/jira/browse/HBASE-17294
> Project: HBase
> Issue Type: Sub-task
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Attachments: HBASE-17294-V01.patch, HBASE-17294-V02.patch,
> HBASE-17294-V03.patch
>
>
> We would like to have a single external knob to control memstore compaction.
> Possible memstore compaction policies are none, basic, and eager.
> This sub-task allows to set this property at the column family level at table
> creation time:
> {code}
> create ‘’,
>{NAME => ‘’,
> IN_MEMORY_COMPACTION => ‘’}
> {code}
> or to set this at the global configuration level by setting the property in
> hbase-site.xml, with BASIC being the default value:
> {code}
>
> hbase.hregion.compacting.memstore.type
>
>
> {code}
> The values used in this property can change as memstore compaction policies
> evolve over time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-17001) [RegionServer] Implement enforcement of quota violation policies
[ https://issues.apache.org/jira/browse/HBASE-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-17001: --- Fix Version/s: 2.0.0 > [RegionServer] Implement enforcement of quota violation policies > > > Key: HBASE-17001 > URL: https://issues.apache.org/jira/browse/HBASE-17001 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > > When the master enacts a quota violation policy, the RegionServers need to > actually enforce that policy per its definition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-17305) Two active HBase Masters can run at the same time under certain circumstances
[ https://issues.apache.org/jira/browse/HBASE-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746506#comment-15746506 ] Harsh J commented on HBASE-17305: - Note that its sorta possible to simulate this by forcing a deletion of znode. If the previous active master is pre-assignment phase, and the new active moves to assignment after the deletion, then both end up trying to assign over the cluster. The failure of one master only ever happens if log splitting is still involved (thanks to HDFS' lease fencing). > Two active HBase Masters can run at the same time under certain circumstances > -- > > Key: HBASE-17305 > URL: https://issues.apache.org/jira/browse/HBASE-17305 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 2.0.0 >Reporter: Esteban Gutierrez >Assignee: Esteban Gutierrez >Priority: Critical > > This needs a little more investigation, but we found a very edgy case when > the active master is restarted and a stand-by master tries to become active, > however the original active master was able to become the active master again > and just before the standby master passed the point of the transition to > become active we ended up with two active masters running at the same time. > Assuming the clock on both masters were accurate to milliseconds, this race > happened in less than 85ms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17294) External Configuration for Memory Compaction
[
https://issues.apache.org/jira/browse/HBASE-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eshcar Hillel updated HBASE-17294:
--
Attachment: HBASE-17294-V03.patch
> External Configuration for Memory Compaction
> -
>
> Key: HBASE-17294
> URL: https://issues.apache.org/jira/browse/HBASE-17294
> Project: HBase
> Issue Type: Sub-task
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Attachments: HBASE-17294-V01.patch, HBASE-17294-V02.patch,
> HBASE-17294-V03.patch
>
>
> We would like to have a single external knob to control memstore compaction.
> Possible memstore compaction policies are none, basic, and eager.
> This sub-task allows to set this property at the column family level at table
> creation time:
> {code}
> create ‘’,
>{NAME => ‘’,
> IN_MEMORY_COMPACTION => ‘’}
> {code}
> or to set this at the global configuration level by setting the property in
> hbase-site.xml, with BASIC being the default value:
> {code}
>
> hbase.hregion.compacting.memstore.type
>
>
> {code}
> The values used in this property can change as memstore compaction policies
> evolve over time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17300) Concurrently calling checkAndPut with expected value as null returns true unexpectedly
[
https://issues.apache.org/jira/browse/HBASE-17300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746476#comment-15746476
]
Andrew Purtell commented on HBASE-17300:
The client makes it appear its synchronous so this is not incorrect. I'm just
letting you know on the master it is not.
> Concurrently calling checkAndPut with expected value as null returns true
> unexpectedly
> --
>
> Key: HBASE-17300
> URL: https://issues.apache.org/jira/browse/HBASE-17300
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.23, 1.2.4
>Reporter: Samarth Jain
> Attachments: HBASE-17300.patch
>
>
> Attached is the test case. I have added some comments so hopefully the test
> makes sense. It actually is causing test failures on the Phoenix branches.
> The test fails consistently using HBase-0.98.23. It exhibits flappy behavior
> with the 1.2 branch (failed twice in 5 tries).
> {code}
> @Test
> public void testNullCheckAndPut() throws Exception {
> try (HBaseAdmin admin = TEST_UTIL.getHBaseAdmin()) {
> Callable c1 = new CheckAndPutCallable();
> Callable c2 = new CheckAndPutCallable();
> ExecutorService e = Executors.newFixedThreadPool(5);
> Future f1 = e.submit(c1);
> Future f2 = e.submit(c2);
> assertTrue(f1.get() || f2.get());
> assertFalse(f1.get() && f2.get());
> }
> }
> }
>
>
> private static final class CheckAndPutCallable implements
> Callable {
> @Override
> public Boolean call() throws Exception {
> byte[] rowToLock = "ROW".getBytes();
> byte[] colFamily = "COLUMN_FAMILY".getBytes();
> byte[] column = "COLUMN".getBytes();
> byte[] newValue = "NEW_VALUE".getBytes();
> byte[] oldValue = "OLD_VALUE".getBytes();
> byte[] tableName = "table".getBytes();
> boolean acquired = false;
> try (HBaseAdmin admin = TEST_UTIL.getHBaseAdmin()) {
> HTableDescriptor tableDesc = new
> HTableDescriptor(TableName.valueOf(tableName));
> HColumnDescriptor columnDesc = new
> HColumnDescriptor(colFamily);
> columnDesc.setTimeToLive(600);
> tableDesc.addFamily(columnDesc);
> try {
> admin.createTable(tableDesc);
> } catch (TableExistsException e) {
> // ignore
> }
> try (HTableInterface table =
> admin.getConnection().getTable(tableName)) {
> Put put = new Put(rowToLock);
> put.add(colFamily, column, oldValue); // add a row
> with column set to oldValue
> table.put(put);
> put = new Put(rowToLock);
> put.add(colFamily, column, newValue);
> // only one of the threads should be able to get
> return value of true for the expected value of oldValue
> acquired = table.checkAndPut(rowToLock, colFamily,
> column, oldValue, put);
> if (!acquired) {
>// if a thread didn't get true before, then it
> shouldn't get true this time either
>// because the column DOES exist
>acquired = table.checkAndPut(rowToLock, colFamily,
> column, null, put);
> }
> }
> }
> }
> return acquired;
> }
> }
> {code}
> cc [~apurtell], [~jamestaylor], [~lhofhansl].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-15532) core favored nodes enhancements
[ https://issues.apache.org/jira/browse/HBASE-15532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thiruvel Thirumoolan resolved HBASE-15532. -- Resolution: Duplicate This is being replaced with jiras with smaller scope as part of HBASE-15531 per [~devaraj] suggestion. > core favored nodes enhancements > --- > > Key: HBASE-15532 > URL: https://issues.apache.org/jira/browse/HBASE-15532 > Project: HBase > Issue Type: Sub-task >Reporter: Francis Liu >Assignee: Thiruvel Thirumoolan > Fix For: 2.0.0 > > Attachments: HBASE-15532.master.000.patch, > HBASE-15532.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14417) Incremental backup and bulk loading
[ https://issues.apache.org/jira/browse/HBASE-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-14417: --- Description: Currently, incremental backup is based on WAL files. Bulk data loading bypasses WALs for obvious reasons, breaking incremental backups. The only way to continue backups after bulk loading is to create new full backup of a table. This may not be feasible for customers who do bulk loading regularly (say, every day). Here is the review board: https://reviews.apache.org/r/54258/ Google doc for design: https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE was: Currently, incremental backup is based on WAL files. Bulk data loading bypasses WALs for obvious reasons, breaking incremental backups. The only way to continue backups after bulk loading is to create new full backup of a table. This may not be feasible for customers who do bulk loading regularly (say, every day). Google doc for design: https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE > Incremental backup and bulk loading > --- > > Key: HBASE-14417 > URL: https://issues.apache.org/jira/browse/HBASE-14417 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Ted Yu >Priority: Critical > Labels: backup > Fix For: 2.0.0 > > Attachments: 14417-tbl-ext.v10.txt, 14417-tbl-ext.v11.txt, > 14417-tbl-ext.v9.txt, 14417.v1.txt, 14417.v11.txt, 14417.v13.txt, > 14417.v2.txt, 14417.v21.txt, 14417.v23.txt, 14417.v24.txt, 14417.v25.txt, > 14417.v6.txt > > > Currently, incremental backup is based on WAL files. Bulk data loading > bypasses WALs for obvious reasons, breaking incremental backups. The only way > to continue backups after bulk loading is to create new full backup of a > table. This may not be feasible for customers who do bulk loading regularly > (say, every day). > Here is the review board: > https://reviews.apache.org/r/54258/ > Google doc for design: > https://docs.google.com/document/d/1ACCLsecHDvzVSasORgqqRNrloGx4mNYIbvAU7lq5lJE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-17302) The region flush request disappeared from flushQueue
[
https://issues.apache.org/jira/browse/HBASE-17302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-17302:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Resolving for now.
Can reopen when branch-1.3 opens.
> The region flush request disappeared from flushQueue
>
>
> Key: HBASE-17302
> URL: https://issues.apache.org/jira/browse/HBASE-17302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 0.98.23, 1.2.4
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17302-branch-1.2-v1.patch,
> HBASE-17302-branch-master-v1.patch
>
>
> Region has too many store files delaying flush up to blockingWaitTime ms, and
> the region flush request is requeued into the flushQueue.
> When the region flush request is requeued into the flushQueue frequently, the
> request is inexplicably disappeared sometimes.
> But regionsInQueue still contains the information of the region request,
> which leads to new flush request can not be inserted into the flushQueue.
> Then, the region will not do flush anymore.
> In order to locate the problem, I added a lot of log in the code.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> private boolean flushRegion(final HRegion region, final boolean
> emergencyFlush) {
> long startTime = 0;
> synchronized (this.regionsInQueue) {
> FlushRegionEntry fqe = this.regionsInQueue.remove(region);
> // Use the start time of the FlushRegionEntry if available
> if (fqe != null) {
> startTime = fqe.createTime;
> }
> if (fqe != null && emergencyFlush) {
> // Need to remove from region from delay queue. When NOT an
> // emergencyFlush, then item was removed via a flushQueue.poll.
> flushQueue.remove(fqe);
> }
> }
> {code}
> When encountered emergencyFlush, the region flusher will be removed from the
> flushQueue.
> By comparing the flushQueue content before and after remove, RegionA should
> have been removed, it is possible to remove RegionB.
> {code:title=MemStoreFlusher.java|borderStyle=solid}
> public boolean equals(Object obj) {
> if (this == obj) {
> return true;
> }
> if (obj == null || getClass() != obj.getClass()) {
> return false;
> }
> Delayed other = (Delayed) obj;
> return compareTo(other) == 0;
> }
> {code}
> FlushRegionEntry in achieving the equals function, only comparison of the
> delay time, if different regions of the same delay time, it is possible that
> A wrong B.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-17306) IntegrationTestRSGroup#testRegionMove may fail due to region server not online
[
https://issues.apache.org/jira/browse/HBASE-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746390#comment-15746390
]
Ted Yu commented on HBASE-17306:
IntegrationTestingUtility#restoreCluster() should return the value returned by
restoreInitialStatus() :
{code}
diff --git
a/hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestingUtility.java
b/hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestingUtility.java
index fcda1b0..b6a6549 100644
---
a/hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestingUtility.java
+++
b/hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestingUtility.java
@@ -94,12 +94,13 @@ public class IntegrationTestingUtility extends
HBaseTestingUtility {
* Restores the cluster to the initial state if it is a distributed cluster,
otherwise, shutdowns the
* mini cluster.
*/
- public void restoreCluster() throws IOException {
+ public boolean restoreCluster() throws IOException {
if (isDistributedCluster()) {
- getHBaseClusterInterface().restoreInitialStatus();
+ return getHBaseClusterInterface().restoreInitialStatus();
} else {
try {
shutdownMiniCluster();
+return true;
} catch (Exception e) {
// re-wrap into IOException
throw new IOException(e);
{code}
Should I open another JIRA for the above change ?
> IntegrationTestRSGroup#testRegionMove may fail due to region server not online
> --
>
> Key: HBASE-17306
> URL: https://issues.apache.org/jira/browse/HBASE-17306
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Priority: Minor
> Attachments: 17306.v1.txt
>
>
> {code}
> 2016-12-13 05:26:57,965|INFO|MainThread|machine.py:145 - run()|2)
> testRegionMove(org.apache.hadoop.hbase.rsgroup.IntegrationTestRSGroup)
> 2016-12-13 05:26:57,965|INFO|MainThread|machine.py:145 -
> run()|org.apache.hadoop.hbase.constraint.ConstraintException:
> org.apache.hadoop.hbase.constraint.ConstraintException:
> Server ctr-e77-1481596162056-0240-01-05.a.com:16020 is not an online
> server in default group.
> 2016-12-13 05:26:57,966|INFO|MainThread|machine.py:145 - run()|at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveServers(RSGroupAdminServer.java:135)
> 2016-12-13 05:26:57,966|INFO|MainThread|machine.py:145 - run()|at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveServers(RSGroupAdminEndpoint.java:169)
> 2016-12-13 05:26:57,966|INFO|MainThread|machine.py:145 - run()|at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.
> callMethod(RSGroupAdminProtos.java:11136)
> 2016-12-13 05:26:57,966|INFO|MainThread|machine.py:145 - run()|at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:679)
> 2016-12-13 05:26:57,966|INFO|MainThread|machine.py:145 - run()|at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2
> {code}
> Shortly before the test failure, the server was shutdown:
> {code}
> 2016-12-13 05:21:25,428 INFO
> [MASTER_SERVER_OPERATIONS-ctr-e77-1481596162056-0240-01-08:2-4]
> handler.ServerShutdownHandler: Finished processing of shutdown of ctr-
> e77-1481596162056-0240-01-05.a.com,16020,1481606309159
> ...
> 2016-12-13 05:26:57,935 INFO
> [RpcServer.FifoWFPBQ.priority.handler=19,queue=1,port=2]
> master.ServerManager: Registering
> server=ctr-e77-1481596162056-0240-01-05.hwx. site,16020,1481606803303
> 2016-12-13 05:27:06,219 DEBUG [main-EventThread]
> zookeeper.RegionServerTracker: Added tracking of RS
> /hbase-secure/rs/ctr-e77-1481596162056-0240-01-05.a.com,16020,
> 1481606803303
> {code}
> The registration of the new server (start code1481606803303) happened shortly
> after the test failure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
