[jira] [Created] (HBASE-19626) Rename Cell.DataType to Cell.Type
Chia-Ping Tsai created HBASE-19626: -- Summary: Rename Cell.DataType to Cell.Type Key: HBASE-19626 URL: https://issues.apache.org/jira/browse/HBASE-19626 Project: HBase Issue Type: Bug Reporter: Chia-Ping Tsai Priority: Minor Fix For: 2.0.0 Align the name with KeyValue.Type. Also, it is the return type of Cell.getType() so the qualifier "Data" is inappropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19550) Wrap the cell passed via Mutation#add(Cell) to be of ExtendedCell
[ https://issues.apache.org/jira/browse/HBASE-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19550: --- Summary: Wrap the cell passed via Mutation#add(Cell) to be of ExtendedCell (was: Wrap the Mutation in cp layer to make sure all passed cells are of ExtendedCell) > Wrap the cell passed via Mutation#add(Cell) to be of ExtendedCell > - > > Key: HBASE-19550 > URL: https://issues.apache.org/jira/browse/HBASE-19550 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19550.v0.patch, HBASE-19550.v1.patch > > > We assume all cells in server are of ExtendedCell. However, cp user can add > their cell impl via Put#add(Cell) in observer. That will cause > UnsupportedOperationException when rs try to update the cell's timestamp and > seq Id. We should do something for cp user...For example, wrap the passed > cells to be a extendcell type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-17615) Use nonce and procedure v2 for add/remove replication peer
[ https://issues.apache.org/jira/browse/HBASE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang resolved HBASE-17615. Resolution: Duplicate Duplicate with HBASE-19397 > Use nonce and procedure v2 for add/remove replication peer > -- > > Key: HBASE-17615 > URL: https://issues.apache.org/jira/browse/HBASE-17615 > Project: HBase > Issue Type: Sub-task > Components: Replication >Affects Versions: 2.0.0 >Reporter: Guanghao Zhang > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19133) Transfer big cells or upserted/appended cells into MSLAB upon flattening to CellChunkMap
[ https://issues.apache.org/jira/browse/HBASE-19133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303578#comment-16303578 ] Anoop Sam John commented on HBASE-19133: Put some minor comments on RB. Looks good overall. > Transfer big cells or upserted/appended cells into MSLAB upon flattening to > CellChunkMap > > > Key: HBASE-19133 > URL: https://issues.apache.org/jira/browse/HBASE-19133 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Gali Sheffi > Attachments: HBASE-19133-V01.patch, HBASE-19133-V02.patch, > HBASE-19133.01.patch, HBASE-19133.02.patch, HBASE-19133.03.patch, > HBASE-19133.04.patch, HBASE-19133.05.patch, HBASE-19133.06.patch, > HBASE-19133.07.patch, HBASE-19133.08.patch, HBASE-19133.09.patch, > HBASE-19133.10.patch, HBASE-19133.11.patch > > > CellChunkMap Segment index requires all cell data to be written in the MSLAB > Chunks. Eventhough MSLAB is enabled, cells bigger than chunk size or > upserted/incremented/appended cells are still allocated on the JVM stack. If > such cells are found in the process of flattening into CellChunkMap > (in-memory-flush) they need to be copied into MSLAB. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303573#comment-16303573 ] Guanghao Zhang commented on HBASE-19573: Attach a 005 patch to fix checkstyle warnings. > Rewrite ReplicationPeer with the new replication storage interface > -- > > Key: HBASE-19573 > URL: https://issues.apache.org/jira/browse/HBASE-19573 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19573.HBASE-19397.001.patch, > HBASE-19573.HBASE-19397.002.patch, HBASE-19573.HBASE-19397.003.patch, > HBASE-19573.HBASE-19397.004.patch, HBASE-19573.HBASE-19397.005.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19617: -- Attachment: HBASE-19617-HBASE-19397-v1.patch > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19617-HBASE-19397-v1.patch, > HBASE-19617-HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19573: --- Attachment: HBASE-19573.HBASE-19397.005.patch > Rewrite ReplicationPeer with the new replication storage interface > -- > > Key: HBASE-19573 > URL: https://issues.apache.org/jira/browse/HBASE-19573 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19573.HBASE-19397.001.patch, > HBASE-19573.HBASE-19397.002.patch, HBASE-19573.HBASE-19397.003.patch, > HBASE-19573.HBASE-19397.004.patch, HBASE-19573.HBASE-19397.005.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19621: --- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) Pushed to master and branch-2. > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19621.master.001.patch, > HBASE-19621.master.002.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > putConfiguration > putAllConfiguration > putPeerData > putAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303547#comment-16303547 ] Jingyun Tian commented on HBASE-19358: -- [~Apache9] ok. I will update a new patch later. > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358-v7.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303544#comment-16303544 ] Jingyun Tian commented on HBASE-19358: -- [~carp84] thx for your help. I will try to provide one for branch-1 asap. > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358-v7.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19618: --- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks [~Apache9] for reviewing. FYI [~openinx] > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch, HBASE-19618.master.003.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303539#comment-16303539
]
Hadoop QA commented on HBASE-19573:
---
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are 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 1 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
6s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} HBASE-19397 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
9s{color} | {color:red} hbase-replication: The patch generated 2 new + 8
unchanged - 1 fixed = 10 total (was 9) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
51s{color} | {color:red} hbase-server: The patch generated 4 new + 0 unchanged
- 0 fixed = 4 total (was 0) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
14s{color} | {color:red} hbase-mapreduce: The patch generated 1 new + 12
unchanged - 0 fixed = 13 total (was 12) {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} shadedjars {color} | {color:green} 4m
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 26s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}103m 6s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
43s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
4s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}152m 29s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19573 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903680/HBASE-19573.HBASE-19397.004.patch
|
| Optional Tests | asflicense
[jira] [Updated] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19618: --- Issue Type: Improvement (was: Bug) > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch, HBASE-19618.master.003.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303519#comment-16303519 ] Guanghao Zhang commented on HBASE-19618: The failed ut TestReplicationKillMasterRSCompressedWithMultipleWAL is not related. Try it three times locally and all passed. > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch, HBASE-19618.master.003.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303514#comment-16303514
]
Hadoop QA commented on HBASE-19573:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
8s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 1 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
32s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
15s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
7s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
52s{color} | {color:green} HBASE-19397 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-replication: The patch generated 1 new + 8
unchanged - 1 fixed = 9 total (was 9) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
2s{color} | {color:red} hbase-server: The patch generated 4 new + 0 unchanged -
0 fixed = 4 total (was 0) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
16s{color} | {color:red} hbase-mapreduce: The patch generated 1 new + 12
unchanged - 0 fixed = 13 total (was 12) {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} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}108m 12s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
47s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
57s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}160m 28s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19573 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903677/HBASE-19573.HBASE-19397.003.patch
|
| Optional Tests | asflicense
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303512#comment-16303512 ] Duo Zhang commented on HBASE-19358: --- Can not leave comments on rb... Overall LGTM. +1. Consider modify your import order rule, 'org' should be placed after 'java'. Thanks. > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358-v7.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[
https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303506#comment-16303506
]
Hadoop QA commented on HBASE-19618:
---
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
27s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication: The patch generated 0 new + 3
unchanged - 9 fixed = 3 total (was 12) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
57s{color} | {color:green} hbase-server: The patch generated 0 new + 184
unchanged - 27 fixed = 184 total (was 211) {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} shadedjars {color} | {color:green} 4m
6s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 41s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 97m 10s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}134m 30s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19618 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903679/HBASE-19618.master.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b32b42f38c6b 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git
[jira] [Commented] (HBASE-19282) CellChunkMap Benchmarking and User Interface
[ https://issues.apache.org/jira/browse/HBASE-19282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303501#comment-16303501 ] ramkrishna.s.vasudevan commented on HBASE-19282: I don't have much comments here. Lets see what others have to say on the defaults here before making this default. > CellChunkMap Benchmarking and User Interface > > > Key: HBASE-19282 > URL: https://issues.apache.org/jira/browse/HBASE-19282 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky > Attachments: CCM Benchmarking.pdf, HBASE-19282-V03.patch, > HBASE-19282-V05.patch, HBASE-19282-V06.patch, HBASE-19282-V06.patch, > HBASE-19282.patch > > > We have made some experiments how working with CellChunkMap (CCM) influences > the performance when running on-heap and off-heap. Based on those results it > is suggested to tie the MSLAB usage (off-heap or on-heap) with CCM index > usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303500#comment-16303500 ] Guanghao Zhang commented on HBASE-19621: Will commit it later if no objection. Thanks [~tedyu] for reviewing. > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Attachments: HBASE-19621.master.001.patch, > HBASE-19621.master.002.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > putConfiguration > putAllConfiguration > putPeerData > putAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19550) Wrap the Mutation in cp layer to make sure all passed cells are of ExtendedCell
[ https://issues.apache.org/jira/browse/HBASE-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303496#comment-16303496 ] ramkrishna.s.vasudevan commented on HBASE-19550: bq.Why not add the default impl of getTag/getTags to ExtendedCell? Not sure whether I had raised this Q before I replied to this over in RB. There was a comment saying having an impl for an interface and just givin default impls does not serve the inheritance purpose. So I first left it with default impl and then changed that to individual impls. I also noted that it will just be repetition of code. If we want to address this lets raise a JIRA and fix it. BTW I thought you were ok for the commit considering the last reply I had given you in RB. :). > Wrap the Mutation in cp layer to make sure all passed cells are of > ExtendedCell > --- > > Key: HBASE-19550 > URL: https://issues.apache.org/jira/browse/HBASE-19550 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19550.v0.patch, HBASE-19550.v1.patch > > > We assume all cells in server are of ExtendedCell. However, cp user can add > their cell impl via Put#add(Cell) in observer. That will cause > UnsupportedOperationException when rs try to update the cell's timestamp and > seq Id. We should do something for cp user...For example, wrap the passed > cells to be a extendcell type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19550) Wrap the Mutation in cp layer to make sure all passed cells are of ExtendedCell
[ https://issues.apache.org/jira/browse/HBASE-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303497#comment-16303497 ] ramkrishna.s.vasudevan commented on HBASE-19550: +1 for this patch. Thanks [~chia7712] > Wrap the Mutation in cp layer to make sure all passed cells are of > ExtendedCell > --- > > Key: HBASE-19550 > URL: https://issues.apache.org/jira/browse/HBASE-19550 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19550.v0.patch, HBASE-19550.v1.patch > > > We assume all cells in server are of ExtendedCell. However, cp user can add > their cell impl via Put#add(Cell) in observer. That will cause > UnsupportedOperationException when rs try to update the cell's timestamp and > seq Id. We should do something for cp user...For example, wrap the passed > cells to be a extendcell type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303485#comment-16303485 ] Yu Li commented on HBASE-19358: --- Patch v7 LGTM, +1, will commit this one with another binding +1. [~tedyu] [~Apache9] Mind take a look at the latest patch when time allows? Thanks. [~tianjingyun] could you prepare a patch for branch-1? Thanks. > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358-v7.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[
https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303477#comment-16303477
]
Hadoop QA commented on HBASE-19358:
---
| (/) *{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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
41s{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} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
46s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} hbase-server: The patch generated 0 new + 50
unchanged - 1 fixed = 50 total (was 51) {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} shadedjars {color} | {color:green} 4m
48s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 57s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m
35s{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}151m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19358 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903673/HBASE-19358-v7.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 31296fe67089 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10710/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10710/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Improve the stability of splitting log when do fail over
>
>
> Key: HB
[jira] [Commented] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[
https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303474#comment-16303474
]
Hadoop QA commented on HBASE-19617:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
8s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 9 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} HBASE-19397 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication: The patch generated 0 new + 1
unchanged - 22 fixed = 1 total (was 23) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{color} | {color:green} hbase-server: The patch generated 0 new + 217
unchanged - 31 fixed = 217 total (was 248) {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} shadedjars {color} | {color:green} 4m
52s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 18s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}122m 11s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}164m 4s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleAsyncWAL
|
| | hadoop.hbase.replication.TestSerialReplication |
| | hadoop.hbase.replication.TestReplicationSource |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19617 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903671/HBASE-19617-HBASE-19397.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle c
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[
https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303470#comment-16303470
]
Hadoop QA commented on HBASE-19621:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
33s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
43s{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} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 9s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
13s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m
5s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
49s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 33s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19621 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903672/HBASE-19621.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 693bf10b80ed 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[
https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303465#comment-16303465
]
Hadoop QA commented on HBASE-19618:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
49s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} hbase-replication: The patch generated 0 new + 3
unchanged - 9 fixed = 3 total (was 12) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
7s{color} | {color:red} hbase-server: The patch generated 2 new + 184 unchanged
- 27 fixed = 186 total (was 211) {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} shadedjars {color} | {color:green} 4m
43s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
14s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}110m
13s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
36s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}152m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19618 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903670/HBASE-19618.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 44d85ca5c821 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| g
[jira] [Updated] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19573: --- Attachment: HBASE-19573.HBASE-19397.004.patch > Rewrite ReplicationPeer with the new replication storage interface > -- > > Key: HBASE-19573 > URL: https://issues.apache.org/jira/browse/HBASE-19573 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19573.HBASE-19397.001.patch, > HBASE-19573.HBASE-19397.002.patch, HBASE-19573.HBASE-19397.003.patch, > HBASE-19573.HBASE-19397.004.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303457#comment-16303457 ] Duo Zhang commented on HBASE-19618: --- +1. > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch, HBASE-19618.master.003.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19618: --- Attachment: HBASE-19618.master.003.patch > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch, HBASE-19618.master.003.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19573: --- Attachment: HBASE-19573.HBASE-19397.003.patch > Rewrite ReplicationPeer with the new replication storage interface > -- > > Key: HBASE-19573 > URL: https://issues.apache.org/jira/browse/HBASE-19573 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19573.HBASE-19397.001.patch, > HBASE-19573.HBASE-19397.002.patch, HBASE-19573.HBASE-19397.003.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19550) Wrap the Mutation in cp layer to make sure all passed cells are of ExtendedCell
[ https://issues.apache.org/jira/browse/HBASE-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303445#comment-16303445 ] Anoop Sam John commented on HBASE-19550: +1 The subject of the Jira giving and impression that we wrap Mutations. We wrap the Cells added directly to Mutation to make sure all cells in List are ExtendedCell types. The wrap will happen whether CP or client. Though at client it make no sense. Just saying that part is ok. So it is not just CP side(We do this considering CP). Pls correct jira subject and/or desc accordingly. Nice work > Wrap the Mutation in cp layer to make sure all passed cells are of > ExtendedCell > --- > > Key: HBASE-19550 > URL: https://issues.apache.org/jira/browse/HBASE-19550 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19550.v0.patch, HBASE-19550.v1.patch > > > We assume all cells in server are of ExtendedCell. However, cp user can add > their cell impl via Put#add(Cell) in observer. That will cause > UnsupportedOperationException when rs try to update the cell's timestamp and > seq Id. We should do something for cp user...For example, wrap the passed > cells to be a extendcell type. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: HBASE-19358-v7.patch > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358-v7.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303441#comment-16303441 ] Ted Yu commented on HBASE-19621: Gone over patch v2. lgtm, pending QA. > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Attachments: HBASE-19621.master.001.patch, > HBASE-19621.master.002.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > putConfiguration > putAllConfiguration > putPeerData > putAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19621: --- Attachment: HBASE-19621.master.002.patch > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Attachments: HBASE-19621.master.001.patch, > HBASE-19621.master.002.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > addConfiguration > addAllConfiguration > addPeerData > addAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19621: --- Description: Add 4 methods for ReplicationPeerConfigBuilder: putConfiguration putAllConfiguration putPeerData putAllPeerData Meanwhile, remove setConfiuration and serPeerData from ReplicationPeerConfigBuilder. Because previous ReplicationPeerConfig didn't support setConfiuration and serPeerData. And previous code used getConfiguration.put or putAll to add configuration. So add methods to keep consistent with old usage. was: Add 4 methods for ReplicationPeerConfigBuilder: addConfiguration addAllConfiguration addPeerData addAllPeerData Meanwhile, remove setConfiuration and serPeerData from ReplicationPeerConfigBuilder. Because previous ReplicationPeerConfig didn't support setConfiuration and serPeerData. And previous code used getConfiguration.put or putAll to add configuration. So add methods to keep consistent with old usage. > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Attachments: HBASE-19621.master.001.patch, > HBASE-19621.master.002.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > putConfiguration > putAllConfiguration > putPeerData > putAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19617: -- Status: Patch Available (was: Open) > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19617-HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19617: -- Attachment: HBASE-19617-HBASE-19397.patch > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19617-HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303437#comment-16303437 ] Anoop Sam John commented on HBASE-18294: bq.Note that with the new patch heap size is always larger than data size because it includes both data and metadata regardless of where it is allocated heap or off heap. At Region level only? What abt the global level (in RSAccounting)? If there also same, it means for off heap we will reach the upper barrier so soon. For off heap the Xmx will be much lower and so the upper barrier. I feel the other way is better. Account data size and heap size how we have now. > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch, > HBASE-18294.11.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19618: --- Attachment: HBASE-19618.master.002.patch > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch, > HBASE-19618.master.002.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19618: --- Summary: Remove replicationQueuesClient.class/replicationQueues.class config and remove table based ReplicationQueuesClient/ReplicationQueues implementation (was: Remove replicationQueuesClient.class/replicationQueues.class config from ReplicationFactory) > Remove replicationQueuesClient.class/replicationQueues.class config and > remove table based ReplicationQueuesClient/ReplicationQueues implementation > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19579) Add peer lock test for shell command list_locks
[ https://issues.apache.org/jira/browse/HBASE-19579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19579: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: HBASE-19397 Status: Resolved (was: Patch Available) Pushed to branch HBASE-19397. Thanks [~zghaobac] for contributing. > Add peer lock test for shell command list_locks > --- > > Key: HBASE-19579 > URL: https://issues.apache.org/jira/browse/HBASE-19579 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19579.HBASE-19397.001.patch, > HBASE-19579.HBASE-19397.002.patch, HBASE-19579.HBASE-19397.002.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[ https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303422#comment-16303422 ] Duo Zhang commented on HBASE-19621: --- [~zghaobac] Let's change to putXXX. > Revisit the methods in ReplicationPeerConfigBuilder > --- > > Key: HBASE-19621 > URL: https://issues.apache.org/jira/browse/HBASE-19621 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Minor > Attachments: HBASE-19621.master.001.patch > > > Add 4 methods for ReplicationPeerConfigBuilder: > addConfiguration > addAllConfiguration > addPeerData > addAllPeerData > Meanwhile, remove setConfiuration and serPeerData from > ReplicationPeerConfigBuilder. > Because previous ReplicationPeerConfig didn't support setConfiuration and > serPeerData. And previous code used getConfiguration.put or putAll to add > configuration. So add methods to keep consistent with old usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19579) Add peer lock test for shell command list_locks
[ https://issues.apache.org/jira/browse/HBASE-19579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303418#comment-16303418 ] Duo Zhang commented on HBASE-19579: --- +1. Let me rebase and commit. > Add peer lock test for shell command list_locks > --- > > Key: HBASE-19579 > URL: https://issues.apache.org/jira/browse/HBASE-19579 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19579.HBASE-19397.001.patch, > HBASE-19579.HBASE-19397.002.patch, HBASE-19579.HBASE-19397.002.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19625) Maven enforcer findings
Olaf Flebbe created HBASE-19625:
---
Summary: Maven enforcer findings
Key: HBASE-19625
URL: https://issues.apache.org/jira/browse/HBASE-19625
Project: HBase
Issue Type: Bug
Components: build
Affects Versions: 1.1.12
Reporter: Olaf Flebbe
While compiling for centos-7 maven enforcer is triggered by several licenses:
https://ci.bigtop.apache.org/job/Bigtop-trunk-packages/COMPONENTS=hbase,OS=centos-7/ws/build/hbase/rpm/BUILD/hbase-1.1.12/hbase-assembly/target/maven-shared-archive-resources/META-INF/LICENSE/*view*/
Here are the diagnostics:
{code}
This product includes OkHttp licensed under the Apache 2.0.
ERROR: Please check this License for acceptability here:
https://www.apache.org/legal/resolved
If it is okay, then update the list named 'non_aggregate_fine' in the
LICENSE.vm file.
If it isn't okay, then revert the change that added the dependency.
More info on the dependency:
com.squareup.okhttp
okhttp
2.4.0
maven central search
g:com.squareup.okhttp AND a:okhttp AND v:2.4.0
project website
https://github.com/square/okhttp/okhttp
project source
https://github.com/square/okhttp/okhttp/
--
This product includes Okio licensed under the Apache 2.0.
ERROR: Please check this License for acceptability here:
https://www.apache.org/legal/resolved
If it is okay, then update the list named 'non_aggregate_fine' in the
LICENSE.vm file.
If it isn't okay, then revert the change that added the dependency.
More info on the dependency:
com.squareup.okio
okio
1.4.0
maven central search
g:com.squareup.okio AND a:okio AND v:1.4.0
project website
https://github.com/square/okio/okio
project source
https://github.com/square/okio/okio/
ERROR: "Java Concurrency in Practice" book annotations dependency found without
license information!
Please find the appropriate license and update supplemental-models.xml or
revert the change that added this dependency.
More info on the dependency:
net.jcip
jcip-annotations
1.0
maven central search
g:net.jcip AND a:jcip-annotations AND v:1.0
project website
http://jcip.net/
project source
${dep.scm.url}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[
https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303408#comment-16303408
]
Hadoop QA commented on HBASE-18294:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 13 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} hbase-server: The patch generated 0 new + 673
unchanged - 57 fixed = 673 total (was 730) {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} shadedjars {color} | {color:green} 4m
39s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}114m 2s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}154m 30s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18294 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903666/HBASE-18294.11.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 5ef29dd95894 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/10705/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10705/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10705/console |
| Powered by | Apache Yetus 0.6.
[jira] [Commented] (HBASE-19624) TestIOFencing hangs
[
https://issues.apache.org/jira/browse/HBASE-19624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303407#comment-16303407
]
Hadoop QA commented on HBASE-19624:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
8s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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: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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
43s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s{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} shadedjars {color} | {color:green} 4m
41s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 56s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}112m
58s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}152m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19624 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903665/HBASE-19624.v0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b3aa3d0c6b39 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10706/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10706/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> TestIOFencing hangs
> ---
>
> Key: HBASE-19624
>
[jira] [Commented] (HBASE-19583) Delete EOL branches - branch-1.0 and branch-1.1
[ https://issues.apache.org/jira/browse/HBASE-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303404#comment-16303404 ] Sean Busbey commented on HBASE-19583: - back in HBASE-16215 [~enis] requested we not delete previous release lines. there's discussion there that's worth reading. Speaking as a RM, I'd rather we not list RMs for non-maintained branches. There's already recognition via the archived VOTEs and ANNOUNCE emails. Since the RM list is used for folks to figure out who to ask for something (namely "include X in release Y" or "hey remember we need another release on line Y"), having a list of prior RMs seems to me likely to encourage folks to reach out for help after the RM in question has already made clear they've finished their part in that release line. > Delete EOL branches - branch-1.0 and branch-1.1 > --- > > Key: HBASE-19583 > URL: https://issues.apache.org/jira/browse/HBASE-19583 > Project: HBase > Issue Type: Bug >Reporter: Appy >Priority: Minor > > wdys [~enis] [~ndimiduk]? > This needs updating too - http://hbase.apache.org/book.html#_release_managers. > I think we should mention RMs for all branches, even eols, if only in other > table. Good way to recognize past efforts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config from ReplicationFactory
[
https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303369#comment-16303369
]
Hadoop QA commented on HBASE-19618:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 4m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
54s{color} | {color:red} hbase-server: The patch generated 2 new + 210
unchanged - 1 fixed = 212 total (was 211) {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} shadedjars {color} | {color:green} 3m
56s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 16s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
12s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}136m 20s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}172m 52s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.security.access.TestCoprocessorWhitelistMasterObserver |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19618 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903603/HBASE-19618.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f07a80dfb102 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31
19:38:41 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bf
[jira] [Updated] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-18294: -- Attachment: HBASE-18294.11.patch > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch, > HBASE-18294.11.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19624) TestIOFencing hangs
[
https://issues.apache.org/jira/browse/HBASE-19624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19624:
---
Status: Patch Available (was: Open)
> TestIOFencing hangs
> ---
>
> Key: HBASE-19624
> URL: https://issues.apache.org/jira/browse/HBASE-19624
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-19624.v0.patch
>
>
> RS calls CompactSplit#join to cease all compactSplit threads.
> {code:title=CompactSplit.java}
> private void waitFor(ThreadPoolExecutor t, String name) {
> boolean done = false;
> while (!done) {
> try {
> done = t.awaitTermination(60, TimeUnit.SECONDS);
> LOG.info("Waiting for " + name + " to finish...");
> if (!done) {
> t.shutdownNow();
> }
> } catch (InterruptedException ie) {
> LOG.warn("Interrupted waiting for " + name + " to finish...");
> }
> }
> }
> {code}
> In the meantime, the async wal may wait for the sync signal. However, the
> single won't happen as the wal sync is failed.
> {code}
> synchronized long get(long timeoutNs) throws InterruptedException,
> ExecutionException, TimeoutIOException {
> final long done = System.nanoTime() + timeoutNs;
> while (!isDone()) {
> wait(1000);
> if (System.nanoTime() >= done) {
> throw new TimeoutIOException(
> "Failed to get sync result after " +
> TimeUnit.NANOSECONDS.toMillis(timeoutNs)
> + " ms for txid=" + this.txid + ", WAL system stuck?");
> }
> }
> if (this.throwable != null) {
> throw new ExecutionException(this.throwable);
> }
> return this.doneTxid;
> }
> {code}
> When we shutdown the mini cluster, JVMClusterUtil#shutdown sends the
> interrupt single to all rs threads. And then catching the
> InterruptedException cause compactionsplit to skip the #shutdownNow, hence
> the compactionsplit threads were up until timeout (default is 5 min).
> {code}
> for (int i = 0; i < 100; ++i) {
> boolean atLeastOneLiveServer = false;
> for (RegionServerThread t : regionservers) {
> if (t.isAlive()) {
> atLeastOneLiveServer = true;
> try {
> LOG.warn("RegionServerThreads remaining, give one more chance
> before interrupting");
> t.join(1000);
> } catch (InterruptedException e) {
> wasInterrupted = true;
> }
> }
> }
> if (!atLeastOneLiveServer) break;
> for (RegionServerThread t : regionservers) {
> if (t.isAlive()) {
> LOG.warn("RegionServerThreads taking too long to stop,
> interrupting");
> t.interrupt();
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[
https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303362#comment-16303362
]
Hadoop QA commented on HBASE-19358:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
27s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{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} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
52s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
8s{color} | {color:red} hbase-server: The patch generated 8 new + 50 unchanged
- 1 fixed = 58 total (was 51) {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} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 37s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}106m 19s{color}
| {color:red} hbase-server in the patch failed. {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}149m 6s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19358 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903632/HBASE-19358-v6.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 644a64fb7887 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/10701/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/10701/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10701/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10701/console |
| Powered by | Apache
[jira] [Updated] (HBASE-19624) TestIOFencing hangs
[
https://issues.apache.org/jira/browse/HBASE-19624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19624:
---
Attachment: HBASE-19624.v0.patch
To resolve this issue, we can lower the wait time to sync or call shutdownNow
when catching the InterruptedException. I prefer the later since it makes sense
to interrupt all threads when the InterruptedException happens.
> TestIOFencing hangs
> ---
>
> Key: HBASE-19624
> URL: https://issues.apache.org/jira/browse/HBASE-19624
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-19624.v0.patch
>
>
> RS calls CompactSplit#join to cease all compactSplit threads.
> {code:title=CompactSplit.java}
> private void waitFor(ThreadPoolExecutor t, String name) {
> boolean done = false;
> while (!done) {
> try {
> done = t.awaitTermination(60, TimeUnit.SECONDS);
> LOG.info("Waiting for " + name + " to finish...");
> if (!done) {
> t.shutdownNow();
> }
> } catch (InterruptedException ie) {
> LOG.warn("Interrupted waiting for " + name + " to finish...");
> }
> }
> }
> {code}
> In the meantime, the async wal may wait for the sync signal. However, the
> single won't happen as the wal sync is failed.
> {code}
> synchronized long get(long timeoutNs) throws InterruptedException,
> ExecutionException, TimeoutIOException {
> final long done = System.nanoTime() + timeoutNs;
> while (!isDone()) {
> wait(1000);
> if (System.nanoTime() >= done) {
> throw new TimeoutIOException(
> "Failed to get sync result after " +
> TimeUnit.NANOSECONDS.toMillis(timeoutNs)
> + " ms for txid=" + this.txid + ", WAL system stuck?");
> }
> }
> if (this.throwable != null) {
> throw new ExecutionException(this.throwable);
> }
> return this.doneTxid;
> }
> {code}
> When we shutdown the mini cluster, JVMClusterUtil#shutdown sends the
> interrupt single to all rs threads. And then catching the
> InterruptedException cause compactionsplit to skip the #shutdownNow, hence
> the compactionsplit threads were up until timeout (default is 5 min).
> {code}
> for (int i = 0; i < 100; ++i) {
> boolean atLeastOneLiveServer = false;
> for (RegionServerThread t : regionservers) {
> if (t.isAlive()) {
> atLeastOneLiveServer = true;
> try {
> LOG.warn("RegionServerThreads remaining, give one more chance
> before interrupting");
> t.join(1000);
> } catch (InterruptedException e) {
> wasInterrupted = true;
> }
> }
> }
> if (!atLeastOneLiveServer) break;
> for (RegionServerThread t : regionservers) {
> if (t.isAlive()) {
> LOG.warn("RegionServerThreads taking too long to stop,
> interrupting");
> t.interrupt();
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19624) TestIOFencing hangs
Chia-Ping Tsai created HBASE-19624:
--
Summary: TestIOFencing hangs
Key: HBASE-19624
URL: https://issues.apache.org/jira/browse/HBASE-19624
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Fix For: 2.0.0
RS calls CompactSplit#join to cease all compactSplit threads.
{code:title=CompactSplit.java}
private void waitFor(ThreadPoolExecutor t, String name) {
boolean done = false;
while (!done) {
try {
done = t.awaitTermination(60, TimeUnit.SECONDS);
LOG.info("Waiting for " + name + " to finish...");
if (!done) {
t.shutdownNow();
}
} catch (InterruptedException ie) {
LOG.warn("Interrupted waiting for " + name + " to finish...");
}
}
}
{code}
In the meantime, the async wal may wait for the sync signal. However, the
single won't happen as the wal sync is failed.
{code}
synchronized long get(long timeoutNs) throws InterruptedException,
ExecutionException, TimeoutIOException {
final long done = System.nanoTime() + timeoutNs;
while (!isDone()) {
wait(1000);
if (System.nanoTime() >= done) {
throw new TimeoutIOException(
"Failed to get sync result after " +
TimeUnit.NANOSECONDS.toMillis(timeoutNs)
+ " ms for txid=" + this.txid + ", WAL system stuck?");
}
}
if (this.throwable != null) {
throw new ExecutionException(this.throwable);
}
return this.doneTxid;
}
{code}
When we shutdown the mini cluster, JVMClusterUtil#shutdown sends the interrupt
single to all rs threads. And then catching the InterruptedException cause
compactionsplit to skip the #shutdownNow, hence the compactionsplit threads
were up until timeout (default is 5 min).
{code}
for (int i = 0; i < 100; ++i) {
boolean atLeastOneLiveServer = false;
for (RegionServerThread t : regionservers) {
if (t.isAlive()) {
atLeastOneLiveServer = true;
try {
LOG.warn("RegionServerThreads remaining, give one more chance
before interrupting");
t.join(1000);
} catch (InterruptedException e) {
wasInterrupted = true;
}
}
}
if (!atLeastOneLiveServer) break;
for (RegionServerThread t : regionservers) {
if (t.isAlive()) {
LOG.warn("RegionServerThreads taking too long to stop,
interrupting");
t.interrupt();
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[
https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303360#comment-16303360
]
Hadoop QA commented on HBASE-18294:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
54s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 13 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
14s{color} | {color:red} hbase-server: The patch generated 2 new + 673
unchanged - 57 fixed = 675 total (was 730) {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} shadedjars {color} | {color:green} 4m
42s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 11s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 37s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}137m 53s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18294 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903627/HBASE-18294.10.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6e37de2531bf 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/10697/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/10697/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10697/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10697/console |
| Powered by | A
[jira] [Commented] (HBASE-19133) Transfer big cells or upserted/appended cells into MSLAB upon flattening to CellChunkMap
[
https://issues.apache.org/jira/browse/HBASE-19133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303357#comment-16303357
]
Hadoop QA commented on HBASE-19133:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
26s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
55s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s{color} | {color:green} hbase-server: The patch generated 0 new + 57
unchanged - 4 fixed = 57 total (was 61) {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} shadedjars {color} | {color:green} 4m
7s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
17m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 92m
27s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}129m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19133 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903623/HBASE-19133-V02.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2ca4a97585fa 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10702/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10702/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Transfer big cells or upserted/appended cells into MSLAB upon flattening to
> CellChunkMap
>
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[
https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303337#comment-16303337
]
Hadoop QA commented on HBASE-19621:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
53s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are 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: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:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s{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:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
29s{color} | {color:red} hbase-client: The patch generated 1 new + 3 unchanged
- 0 fixed = 4 total (was 3) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-replication: The patch generated 2 new + 5
unchanged - 0 fixed = 7 total (was 5) {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} shadedjars {color} | {color:green} 4m
38s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
50s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
12s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 44m 5s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19621 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903613/HBASE-19621.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0d76229b4aa2 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality
[jira] [Commented] (HBASE-19579) Add peer lock test for shell command list_locks
[
https://issues.apache.org/jira/browse/HBASE-19579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1630#comment-1630
]
Hadoop QA commented on HBASE-19579:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
27s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
17s{color} | {color:green} HBASE-19397 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
3s{color} | {color:red} The patch generated 10 new + 65 unchanged - 1 fixed =
75 total (was 66) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
2s{color} | {color:red} The patch generated 4 new + 79 unchanged - 0 fixed = 83
total (was 79) {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} hbaseprotoc {color} | {color:green}
0m 49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {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} | {color:green} 7m
1s{color} | {color:green} hbase-shell 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} 19m 2s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19579 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903615/HBASE-19579.HBASE-19397.002.patch
|
| Optional Tests | asflicense cc unit hbaseprotoc rubocop ruby_lint |
| uname | Linux 56429bd53b0d 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 | HBASE-19397 / 0e53efd00e |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| rubocop | v0.52.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/10703/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/10703/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10703/testReport/ |
| modules | C: hbase-protocol-shaded hbase-shell U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10703/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Add peer lock test for shell command list_locks
> ---
>
> Key: HBASE-19579
> URL: https://issues.apache.org/jira/browse/HBASE-19579
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, Replication
>Reporter: Duo Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-19579.HBASE-19397.001.patch,
> HBASE-19579.HBASE-19397.002.patch, HBASE-19579.HBASE-19397.002.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19619) Modify replication_admin.rb to use ReplicationPeerConfigBuilder
[
https://issues.apache.org/jira/browse/HBASE-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303332#comment-16303332
]
Hadoop QA commented on HBASE-19619:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
51s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.6.0/precommit-patchnames for
instructions. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
3s{color} | {color:red} The patch generated 16 new + 49 unchanged - 4 fixed =
65 total (was 53) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
2s{color} | {color:red} The patch generated 12 new + 47 unchanged - 3 fixed =
59 total (was 50) {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} javadoc {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
3s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 18m 44s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19619 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903610/19619.v4.txt |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux d516a2909b9e 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / 38472e1c07 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| rubocop | v0.52.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/10699/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/10699/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10699/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10699/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Modify replication_admin.rb to use ReplicationPeerConfigBuilder
> ---
>
> Key: HBASE-19619
> URL: https://issues.apache.org/jira/browse/HBASE-19619
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: 19619.v1.txt, 19619.v2.txt, 19619.v3.txt, 19619.v4.txt
>
>
> Here is the error:
> {code}
> Error:
> test_append_peer_namespaces:_works_with_namespaces_array(Hbase::ReplicationAdminTest):
> Java::JavaLang::UnsupportedOperationException:
> java.util.Collections$UnmodifiableCollection.add(java/uti
[jira] [Commented] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303324#comment-16303324
]
Hadoop QA commented on HBASE-19573:
---
| (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 4s{color}
| {color:red} HBASE-19573 does not apply to HBASE-19397. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19573 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12903626/HBASE-19573.HBASE-19397.002.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10700/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Rewrite ReplicationPeer with the new replication storage interface
> --
>
> Key: HBASE-19573
> URL: https://issues.apache.org/jira/browse/HBASE-19573
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, Replication
>Reporter: Duo Zhang
>Assignee: Guanghao Zhang
> Fix For: HBASE-19397
>
> Attachments: HBASE-19573.HBASE-19397.001.patch,
> HBASE-19573.HBASE-19397.002.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-18294: -- Status: Patch Available (was: Open) > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-18294: -- Status: Open (was: Patch Available) > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19487) Remove IterablesUtil Class
[
https://issues.apache.org/jira/browse/HBASE-19487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303317#comment-16303317
]
Appy commented on HBASE-19487:
--
Makes sense [~belugabehr]. +1.
Thanks for making things right here - deleting redundant local copy of
IterableUtils.
> Remove IterablesUtil Class
> --
>
> Key: HBASE-19487
> URL: https://issues.apache.org/jira/browse/HBASE-19487
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
> Attachments: HBASE-19487.1.patch, HBASE-19487.2.patch,
> HBASE-19487.3.patch
>
>
> Remove mostly unused and obsolete class {{IterablesUtil}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303314#comment-16303314 ] Niels Basjes commented on HBASE-19486: -- Jenkins seems to be having problems. This last Hadoop QA post belongs to an older patch. > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303287#comment-16303287 ] Eshcar Hillel commented on HBASE-18294: --- Sorry [~ram_krish] I missed you comment. bq. Probably you should go with || case - check both data + heap or only data. Because for offheap memstore heap won't reach this value. Note that with the new patch heap size is always larger than data size because it includes both data and metadata regardless of where it is allocated heap or off heap. > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19611) Review of QuotaRetriever Class
[
https://issues.apache.org/jira/browse/HBASE-19611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303280#comment-16303280
]
Peter Somogyi commented on HBASE-19611:
---
+1
> Review of QuotaRetriever Class
> --
>
> Key: HBASE-19611
> URL: https://issues.apache.org/jira/browse/HBASE-19611
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Trivial
> Attachments: HBASE-19611.1.patch
>
>
> * Use ArrayDeque instead of LinkedList for performanc
> * Remove use of {{StringUtils.stringifyException}} in favor of SLF4J
> formatting
> * Remove unused imports
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19188) Build fails on branch-1 using maven-3.5.2
[
https://issues.apache.org/jira/browse/HBASE-19188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302966#comment-16302966
]
Xu Jiang edited comment on HBASE-19188 at 12/25/17 1:41 PM:
[~psomogyi] sorry,Is Hbase 1.1.9/1.4.0/1.2.6 building problem？
was (Author: xujiang):
Pater Somogyi sorry,Is Hbase 1.1.9/1.4.0/1.2.6 building problem？
> Build fails on branch-1 using maven-3.5.2
> -
>
> Key: HBASE-19188
> URL: https://issues.apache.org/jira/browse/HBASE-19188
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 1.4.0, 1.3.1, 1.2.6, 1.5.0
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Blocker
> Fix For: 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-19188.branch-1.2.001.patch,
> HBASE-19188.branch-1.2.002.patch
>
>
> With maven 3.5.2 the build fails on branch-1-2, branch-1.3, branch-1.4 and
> branch-1. On branch-1.1, branch-2 and master the build succeeds. With older
> maven versions the build finishes.
> {code:title=Maven version}
> $ mvn -v
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=1024m;
> support was removed in 8.0
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /Users/peter.somogyi/bin/apache-maven-3.5.2
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> {code}
> {code}
> $ mvn clean install -DskipTests
> ...
> [INFO] --- jamon-maven-plugin:2.4.1:translate (default) @ hbase-server ---
> [INFO]
> [INFO] --- maven-antrun-plugin:1.6:run (generate) @ hbase-server ---
> [INFO] Executing tasks
> main:
> log4j:WARN No appenders could be found for logger (org.apache.jasper.JspC).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> [INFO] Logging to org.slf4j.impl.MavenSimpleLogger(org.mortbay.log) via
> org.mortbay.log.Slf4jLog
> java.util.MissingResourceException: Can't find bundle for base name
> org.apache.jasper.resources.LocalStrings, locale en_US
> at
> java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1564)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1387)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:773)
> at org.apache.jasper.compiler.Localizer.(Localizer.java:36)
> at
> org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:103)
> at org.apache.jasper.JspC.initServletContext(JspC.java:1242)
> at org.apache.jasper.JspC.execute(JspC.java:1103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:154)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:270)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:353)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor
[jira] [Comment Edited] (HBASE-19188) Build fails on branch-1 using maven-3.5.2
[
https://issues.apache.org/jira/browse/HBASE-19188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302966#comment-16302966
]
Xu Jiang edited comment on HBASE-19188 at 12/25/17 1:38 PM:
Pater Somogyi sorry,Is Hbase 1.1.9/1.4.0/1.2.6 building problem？
was (Author: xujiang):
@Pater Somogyi sorry,Is Hbase 1.1.9/1.4.0/1.2.6 building problem？
> Build fails on branch-1 using maven-3.5.2
> -
>
> Key: HBASE-19188
> URL: https://issues.apache.org/jira/browse/HBASE-19188
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 1.4.0, 1.3.1, 1.2.6, 1.5.0
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Blocker
> Fix For: 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-19188.branch-1.2.001.patch,
> HBASE-19188.branch-1.2.002.patch
>
>
> With maven 3.5.2 the build fails on branch-1-2, branch-1.3, branch-1.4 and
> branch-1. On branch-1.1, branch-2 and master the build succeeds. With older
> maven versions the build finishes.
> {code:title=Maven version}
> $ mvn -v
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=1024m;
> support was removed in 8.0
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> Maven home: /Users/peter.somogyi/bin/apache-maven-3.5.2
> Java version: 1.8.0_141, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_141.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> {code}
> {code}
> $ mvn clean install -DskipTests
> ...
> [INFO] --- jamon-maven-plugin:2.4.1:translate (default) @ hbase-server ---
> [INFO]
> [INFO] --- maven-antrun-plugin:1.6:run (generate) @ hbase-server ---
> [INFO] Executing tasks
> main:
> log4j:WARN No appenders could be found for logger (org.apache.jasper.JspC).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> [INFO] Logging to org.slf4j.impl.MavenSimpleLogger(org.mortbay.log) via
> org.mortbay.log.Slf4jLog
> java.util.MissingResourceException: Can't find bundle for base name
> org.apache.jasper.resources.LocalStrings, locale en_US
> at
> java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1564)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1387)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:773)
> at org.apache.jasper.compiler.Localizer.(Localizer.java:36)
> at
> org.apache.jasper.compiler.JspRuntimeContext.(JspRuntimeContext.java:103)
> at org.apache.jasper.JspC.initServletContext(JspC.java:1242)
> at org.apache.jasper.JspC.execute(JspC.java:1103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:154)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
> at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:270)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:353)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198)
> at
> org.apache.maven.lifecycle.internal.MojoExecut
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config from ReplicationFactory
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303266#comment-16303266 ] Guanghao Zhang commented on HBASE-19618: Got it. Let me remove it in new patch. > Remove replicationQueuesClient.class/replicationQueues.class config from > ReplicationFactory > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reassigned HBASE-19617: - Assignee: Duo Zhang > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19618) Remove replicationQueuesClient.class/replicationQueues.class config from ReplicationFactory
[ https://issues.apache.org/jira/browse/HBASE-19618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303264#comment-16303264 ] Duo Zhang commented on HBASE-19618: --- I've already removed them when implementing HBASE-19397 as we will remove ReplicationQueues/ReplicationQueuesClient interfaces... > Remove replicationQueuesClient.class/replicationQueues.class config from > ReplicationFactory > --- > > Key: HBASE-19618 > URL: https://issues.apache.org/jira/browse/HBASE-19618 > Project: HBase > Issue Type: Bug >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-19618.master.001.patch > > > When implement the procedure of replication admin operations, we abstract a > replication storage interface in HBASE-19543. So > ReplicationQueues/ReplicationQueuesClient are not used anymore. These > interface are IA.private. So it is ok to remove them. But there are two > config: hbase.region.replica.replication.replicationQueues.class and > hbase.region.replica.replication.replicationQueuesClient.class in > ReplicationFactory. These configs were introduced by HBASE-15867, which only > in 2.0. And the feature development is not active now. In the future, we can > implement the table based replication to replication storage interface. So > let's remove them before release 2.0. > See more details in the discussion of HBASE-19573. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19487) Remove IterablesUtil Class
[
https://issues.apache.org/jira/browse/HBASE-19487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303249#comment-16303249
]
Hudson commented on HBASE-19487:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4283 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4283/])
HBASE-19487 Remove IterablesUtil Class (chia7712: rev
38472e1c07bc48079f4b9766d45e6b64163bd0d4)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java
* (delete)
hbase-common/src/main/java/org/apache/hadoop/hbase/util/IterableUtils.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValueUtil.java
* (edit)
hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValueTestUtil.java
> Remove IterablesUtil Class
> --
>
> Key: HBASE-19487
> URL: https://issues.apache.org/jira/browse/HBASE-19487
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
> Attachments: HBASE-19487.1.patch, HBASE-19487.2.patch,
> HBASE-19487.3.patch
>
>
> Remove mostly unused and obsolete class {{IterablesUtil}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: HBASE-19358-v6.patch > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358-v6.patch, HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19599) Remove ReplicationQueuesClient, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19599: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Rebased and pushed to HBASE-19397. Thanks [~openinx] for reviewing. > Remove ReplicationQueuesClient, use ReplicationQueueStorage directly > > > Key: HBASE-19599 > URL: https://issues.apache.org/jira/browse/HBASE-19599 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19599-HBASE-19397-v1.patch, > HBASE-19599-HBASE-19397-v2.patch, HBASE-19599-HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: (was: HBASE-19358-v5.patch) > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: HBASE-19358-v5.patch > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-19358-v1.patch, HBASE-19358-v4.patch, > HBASE-19358-v5.patch, HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19623) Create the connection to peer cluster async when region server add a replication source.
[ https://issues.apache.org/jira/browse/HBASE-19623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu reassigned HBASE-19623: Assignee: Zheng Hu > Create the connection to peer cluster async when region server add a > replication source. > - > > Key: HBASE-19623 > URL: https://issues.apache.org/jira/browse/HBASE-19623 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Zheng Hu >Assignee: Zheng Hu > > As the discussion in HBASE-19617, After the replication procedure replace > the zookeeper notification , the addPeer operation may be blocked because > the RegionServer will create a connection to peer cluster synchronously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303187#comment-16303187 ] Zheng Hu commented on HBASE-19617: -- bq. Seems we will create the ConnectionImplementation synchronously and since the peer dummy, which means the remote does not exist, we will block on getting cluster id until the retry limit is reached. Yes, It's true. RS will create a Connection to peer cluster when initialize the ReplicationEndpointImpl.Filed an issue HBASE-19623 to address this. > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19623) Create the connection to peer cluster async when region server add a replication source.
Zheng Hu created HBASE-19623: Summary: Create the connection to peer cluster async when region server add a replication source. Key: HBASE-19623 URL: https://issues.apache.org/jira/browse/HBASE-19623 Project: HBase Issue Type: Sub-task Reporter: Zheng Hu As the discussion in HBASE-19617, After the replication procedure replace the zookeeper notification , the addPeer operation may be blocked because the RegionServer will create a connection to peer cluster synchronously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18294) Reduce global heap pressure: flush based on heap occupancy
[ https://issues.apache.org/jira/browse/HBASE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-18294: -- Attachment: HBASE-18294.10.patch > Reduce global heap pressure: flush based on heap occupancy > -- > > Key: HBASE-18294 > URL: https://issues.apache.org/jira/browse/HBASE-18294 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Attachments: HBASE-18294.01.patch, HBASE-18294.02.patch, > HBASE-18294.03.patch, HBASE-18294.04.patch, HBASE-18294.05.patch, > HBASE-18294.06.patch, HBASE-18294.07.patch, HBASE-18294.07.patch, > HBASE-18294.08.patch, HBASE-18294.09.patch, HBASE-18294.10.patch > > > A region is flushed if its memory component exceed a threshold (default size > is 128MB). > A flush policy decides whether to flush a store by comparing the size of the > store to another threshold (that can be configured with > hbase.hregion.percolumnfamilyflush.size.lower.bound). > Currently the implementation (in both cases) compares the data size > (key-value only) to the threshold where it should compare the heap size > (which includes index size, and metadata). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19573) Rewrite ReplicationPeer with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19573: --- Attachment: HBASE-19573.HBASE-19397.002.patch > Rewrite ReplicationPeer with the new replication storage interface > -- > > Key: HBASE-19573 > URL: https://issues.apache.org/jira/browse/HBASE-19573 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Guanghao Zhang > Fix For: HBASE-19397 > > Attachments: HBASE-19573.HBASE-19397.001.patch, > HBASE-19573.HBASE-19397.002.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu reassigned HBASE-19622: Assignee: Zheng Hu > Reimplement ReplicationPeers with the new replication storage interface > --- > > Key: HBASE-19622 > URL: https://issues.apache.org/jira/browse/HBASE-19622 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Guanghao Zhang >Assignee: Zheng Hu > Fix For: HBASE-19397 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303162#comment-16303162 ] Zheng Hu commented on HBASE-19622: -- Currently, Most code of ReplicationPeersZKImpl and ReplicationPeerManager are similar . I'm thinking that how to merge them into a single class. > Reimplement ReplicationPeers with the new replication storage interface > --- > > Key: HBASE-19622 > URL: https://issues.apache.org/jira/browse/HBASE-19622 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Guanghao Zhang > Fix For: HBASE-19397 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19621) Revisit the methods in ReplicationPeerConfigBuilder
[
https://issues.apache.org/jira/browse/HBASE-19621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303151#comment-16303151
]
Ted Yu commented on HBASE-19621:
{code}
+public ReplicationPeerConfigBuilder addConfiguration(String key, String
value) {
+ this.configuration.put(key, value);
{code}
Since key may already exist in this.configuration, method name does't seem to
be accurate.
How about naming it putConfiguration() ?
> Revisit the methods in ReplicationPeerConfigBuilder
> ---
>
> Key: HBASE-19621
> URL: https://issues.apache.org/jira/browse/HBASE-19621
> Project: HBase
> Issue Type: Improvement
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Attachments: HBASE-19621.master.001.patch
>
>
> Add 4 methods for ReplicationPeerConfigBuilder:
> addConfiguration
> addAllConfiguration
> addPeerData
> addAllPeerData
> Meanwhile, remove setConfiuration and serPeerData from
> ReplicationPeerConfigBuilder.
> Because previous ReplicationPeerConfig didn't support setConfiuration and
> serPeerData. And previous code used getConfiguration.put or putAll to add
> configuration. So add methods to keep consistent with old usage.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303146#comment-16303146 ] Duo Zhang commented on HBASE-19617: --- I plan to do this after HBASE-19599 is resolved. And there is another problem, we will block on refreshing peer when adding a dummy peer. Seems we will create the ConnectionImplementation synchronously and since the peer dummy, which means the remote does not exist, we will block on getting cluster id until the retry limit is reached. And if we change to use AsyncConnection later, the refresh may fail since we will fail the construction when we can not get the cluster id. You can see the problem when running TestReplicationAdmin and TestAsyncAdminReplicationApi. I think we should address this. You can open a new issue to address it once you confirm the same problem. Thanks. > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19487) Remove IterablesUtil Class
[
https://issues.apache.org/jira/browse/HBASE-19487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19487:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch. [~belugabehr]
> Remove IterablesUtil Class
> --
>
> Key: HBASE-19487
> URL: https://issues.apache.org/jira/browse/HBASE-19487
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
> Attachments: HBASE-19487.1.patch, HBASE-19487.2.patch,
> HBASE-19487.3.patch
>
>
> Remove mostly unused and obsolete class {{IterablesUtil}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19617) Remove ReplicationQueues, use ReplicationQueueStorage directly
[ https://issues.apache.org/jira/browse/HBASE-19617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303136#comment-16303136 ] Zheng Hu commented on HBASE-19617: -- Is anyone working on this issue ? If no, Could I pick this up ? [~Apache9], [~zghaobac] > Remove ReplicationQueues, use ReplicationQueueStorage directly > -- > > Key: HBASE-19617 > URL: https://issues.apache.org/jira/browse/HBASE-19617 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19576) Introduce builder for ReplicationPeerConfig and make it immutable
[ https://issues.apache.org/jira/browse/HBASE-19576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303135#comment-16303135 ] Guanghao Zhang commented on HBASE-19576: "Return a immutable Map" should belong to API behavior Compatibility? Checked the Compatibility requirements in hbase book : https://hbase.apache.org/book.html#hbase.versioning. But didn't find description for this. Ping [~stack] > Introduce builder for ReplicationPeerConfig and make it immutable > - > > Key: HBASE-19576 > URL: https://issues.apache.org/jira/browse/HBASE-19576 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19576.master.001.patch, > HBASE-19576.master.002.patch, HBASE-19576.master.002.patch, > HBASE-19576.master.003.patch > > > Will introduce a new ReplicationPeerConfigBuilder. And deprecated the old > set* methods in ReplicationPeerConfig. Make the ReplicationPeerConfig we give > out be immutable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19576) Introduce builder for ReplicationPeerConfig and make it immutable
[ https://issues.apache.org/jira/browse/HBASE-19576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303134#comment-16303134 ] Guanghao Zhang commented on HBASE-19576: In this issue, ReplicationPeerConfig's get* method will return a immutable Map/Set. Does this meet our Compatibility requirements for client API? [~stack] BTW: I also saw same change for HColumnDescriptor. See HBASE-18419. > Introduce builder for ReplicationPeerConfig and make it immutable > - > > Key: HBASE-19576 > URL: https://issues.apache.org/jira/browse/HBASE-19576 > Project: HBase > Issue Type: Improvement >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19576.master.001.patch, > HBASE-19576.master.002.patch, HBASE-19576.master.002.patch, > HBASE-19576.master.003.patch > > > Will introduce a new ReplicationPeerConfigBuilder. And deprecated the old > set* methods in ReplicationPeerConfig. Make the ReplicationPeerConfig we give > out be immutable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19133) Transfer big cells or upserted/appended cells into MSLAB upon flattening to CellChunkMap
[ https://issues.apache.org/jira/browse/HBASE-19133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gali Sheffi updated HBASE-19133: Attachment: HBASE-19133-V02.patch > Transfer big cells or upserted/appended cells into MSLAB upon flattening to > CellChunkMap > > > Key: HBASE-19133 > URL: https://issues.apache.org/jira/browse/HBASE-19133 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Gali Sheffi > Attachments: HBASE-19133-V01.patch, HBASE-19133-V02.patch, > HBASE-19133.01.patch, HBASE-19133.02.patch, HBASE-19133.03.patch, > HBASE-19133.04.patch, HBASE-19133.05.patch, HBASE-19133.06.patch, > HBASE-19133.07.patch, HBASE-19133.08.patch, HBASE-19133.09.patch, > HBASE-19133.10.patch, HBASE-19133.11.patch > > > CellChunkMap Segment index requires all cell data to be written in the MSLAB > Chunks. Eventhough MSLAB is enabled, cells bigger than chunk size or > upserted/incremented/appended cells are still allocated on the JVM stack. If > such cells are found in the process of flattening into CellChunkMap > (in-memory-flush) they need to be copied into MSLAB. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19545) Replace getBytes(StandardCharsets.UTF_8) with Bytes.toBytes
[ https://issues.apache.org/jira/browse/HBASE-19545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303130#comment-16303130 ] Chia-Ping Tsai commented on HBASE-19545: The patch is decrepit. Would you please rebase the patch? > Replace getBytes(StandardCharsets.UTF_8) with Bytes.toBytes > --- > > Key: HBASE-19545 > URL: https://issues.apache.org/jira/browse/HBASE-19545 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.0, 2.0.0-beta-1 >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 1.4.1, 2.0.0-beta-2 > > Attachments: HBASE-19545.branch-1.001.patch, > HBASE-19545.master.001.patch, HBASE-19545.master.001.patch > > > On HBASE-19498 [~stack] mentioned that Bytes.toBytes by default uses UTF_8 > encoding so getBytes(StandardCharsets.UTF_8) can be simplified. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19487) Remove IterablesUtil Class
[
https://issues.apache.org/jira/browse/HBASE-19487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303129#comment-16303129
]
Chia-Ping Tsai commented on HBASE-19487:
+1
> Remove IterablesUtil Class
> --
>
> Key: HBASE-19487
> URL: https://issues.apache.org/jira/browse/HBASE-19487
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
> Attachments: HBASE-19487.1.patch, HBASE-19487.2.patch,
> HBASE-19487.3.patch
>
>
> Remove mostly unused and obsolete class {{IterablesUtil}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
