[jira] [Updated] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Guanghao Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-16868:
---
Release Note: 
Add a replicate_all flag to replication peer config. The default value is true, 
which means all user tables (REPLICATION_SCOPE != 0 ) will be replicated to 
peer cluster.
If you add a new peer with no namespace/tablecfs config, the replicate_all flag 
will be true 
If you only need replicate some namespaces or tables,  you need set 
replicate_all flag to false first. Then add special namespaces or table-cfs 
config to the replication peer.

  was:Add a replicate_all flag to replication peer config. The default value is 
true, which means all user tables (REPLICATION_SCOPE != 0 ) will be replicated 
to peer cluster. If you only need replicate some namespaces or tables,  you 
need set replicate_all flag to false first. Then add special namespaces or 
table-cfs config to the replication peer.


> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch, 
> HBASE-16868.master.008.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore

[ramkrishna.s.vasudevan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-18994:
---
Fix Version/s: (was: 2.0.0-beta-1)
   2.0.0-alpha-4

> Decide if META/System tables should use Compacting Memstore or Default 
> Memstore
> ---
>
> Key: HBASE-18994
> URL: https://issues.apache.org/jira/browse/HBASE-18994
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18994.patch, HBASE-18994_1.patch, 
> HBASE-18994_2.patch, HBASE-18994_3.patch
>
>
> HBASE-18992 brought this topic. Currently META is also using Compacting 
> Memstore. We should decide if system tables can go with Default memstore only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore

[Chia-Ping Tsai (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218147#comment-16218147
 ] 

Chia-Ping Tsai commented on HBASE-18994:


+1. BTW, should we put this new config to hbase-default.xml? Or add it to our 
docs? If users add their tables to System namespace, they may complain the 
in-memory compaction setting from {{ColumnFamilyDescriptor}} is not working.

> Decide if META/System tables should use Compacting Memstore or Default 
> Memstore
> ---
>
> Key: HBASE-18994
> URL: https://issues.apache.org/jira/browse/HBASE-18994
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18994.patch, HBASE-18994_1.patch, 
> HBASE-18994_2.patch, HBASE-18994_3.patch
>
>
> HBASE-18992 brought this topic. Currently META is also using Compacting 
> Memstore. We should decide if system tables can go with Default memstore only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Guanghao Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-16868:
---
Attachment: HBASE-16868.master.008.patch

> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch, 
> HBASE-16868.master.008.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19065) HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218146#comment-16218146
 ] 

stack commented on HBASE-19065:
---

How long does it wait?

> HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
> 
>
> Key: HBASE-19065
> URL: https://issues.apache.org/jira/browse/HBASE-19065
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-alpha-4
>
> Attachments: 19065.v1.txt, 19065.v2.txt, 19065.v2.txt
>
>
> When I was debugging bulk load failure, I saw the following in region server 
> log:
> {code}
> 2017-10-17 23:05:28,795 DEBUG 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] regionserver.HRegion: NOT 
> flushing memstore for region mx_, 
> f449669a8b0341e4edbd2ebdacc72094f449669a8b0341e4edbd2ebdacc7209420150711,1504909319142.52d496ba39036e0c2cc9522895ad438f.,
>  flushing=true, writesEnabled=true
> 2017-10-17 23:05:28,796 ERROR 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] 
> access.SecureBulkLoadEndpoint: Failed to complete bulk load
> java.io.IOException: Could not bulk load with an assigned sequential ID 
> because the flush didn't run. Reason for not flushing: Not flushing since 
> already flushing
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:5282)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:292)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:275)
> {code}
> There was concurrent flush which got misinterpreted by bulkLoadHFiles().
> HRegion#bulkLoadHFiles() should wait for the concurrent flush to complete.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19085) Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218143#comment-16218143
 ] 

ramkrishna.s.vasudevan commented on HBASE-19085:


I see. Thanks for the update.

> Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning
> --
>
> Key: HBASE-19085
> URL: https://issues.apache.org/jira/browse/HBASE-19085
> Project: HBase
>  Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
>
> Seems the recent commits have introduced a findbug warning.
>   'org.apache.hadoop.hbase.regionserver.MemStoreSizing overrides equals 
> in MemStoreSize and may not be symmetric'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-19085) Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack resolved HBASE-19085.
---
Resolution: Duplicate

Thanks [~ram_krish] ... [~chia7712] already noticed this. Just committed an 
addendum ..

commit 43a8ac00158e92c3015af7753edd8e835dc6054b
Author: Michael Stack 
Date:   Tue Oct 24 22:40:30 2017 -0700

BASE-19074 Miscellaneous Observer cleanups; ADDEDNUM to fix FindBugs

> Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning
> --
>
> Key: HBASE-19085
> URL: https://issues.apache.org/jira/browse/HBASE-19085
> Project: HBase
>  Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
>
> Seems the recent commits have introduced a findbug warning.
>   'org.apache.hadoop.hbase.regionserver.MemStoreSizing overrides equals 
> in MemStoreSize and may not be symmetric'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Provide Region#waitForFlushes API

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218139#comment-16218139
 ] 

stack commented on HBASE-18906:
---

bq. For flush if there is already a snapshot in progress, we will not take cur 
req.

What will we do? Exception?

bq. Compaction do we have this way? I dont think so. 

if an ongoing Compaction, we probably just queue the new compaction

bq. So the plan here is to have a waitForFlushes(long timeout) API in Region

What would this wait on?

> Provide Region#waitForFlushes API
> -
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18906.patch
>
>
> Expose an API for the CPs to wait for all on going flushes in a Region. The 
> API should support taking a time out.
> Background
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-6721) RegionServer Group based Assignment

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218138#comment-16218138
 ] 

Hudson commented on HBASE-6721:
---

FAILURE: Integrated in Jenkins build HBase-1.5 #115 (See 
[https://builds.apache.org/job/HBase-1.5/115/])
Amend HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 
(apurtell: rev 089acc74dad0bd6368e4bb584fde2a84b8c8ab56)
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java


> RegionServer Group based Assignment
> ---
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
>  Issue Type: New Feature
>  Components: regionserver
>Reporter: Francis Liu
>Assignee: Francis Liu
>  Labels: hbase-6721
> Fix For: 2.0.0
>
> Attachments: 6721-master-webUI.patch, HBASE-6721 
> GroupBasedLoadBalancer Sequence Diagram.xml, HBASE-6721-DesigDoc.pdf, 
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, 
> HBASE-6721_0.98_2.patch, HBASE-6721_10.patch, HBASE-6721_11.patch, 
> HBASE-6721_12.patch, HBASE-6721_13.patch, HBASE-6721_14.patch, 
> HBASE-6721_15.patch, HBASE-6721_8.patch, HBASE-6721_9.patch, 
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch, 
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch, 
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch, 
> HBASE-6721_94_7.patch, HBASE-6721_98_1.patch, HBASE-6721_98_2.patch, 
> HBASE-6721_hbase-6721_addendum.patch, HBASE-6721_trunk.patch, 
> HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch, 
> HBASE-6721_trunk2.patch, balanceCluster Sequence Diagram.svg, 
> hbase-6721-v15-branch-1.1.patch, hbase-6721-v16.patch, hbase-6721-v17.patch, 
> hbase-6721-v18.patch, hbase-6721-v19.patch, hbase-6721-v20.patch, 
> hbase-6721-v21.patch, hbase-6721-v22.patch, hbase-6721-v23.patch, 
> hbase-6721-v25.patch, hbase-6721-v26.patch, hbase-6721-v26_draft1.patch, 
> hbase-6721-v27.patch, hbase-6721-v27.patch, hbase-6721-v27.patch.txt, 
> hbase-6721-v28.patch, hbase-6721-v28.patch, hbase-6721-v29.patch, 
> immediateAssignments Sequence Diagram.svg, randomAssignment Sequence 
> Diagram.svg, retainAssignment Sequence Diagram.svg, roundRobinAssignment 
> Sequence Diagram.svg
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will 
> be serving out regions from a number of different tables owned by various 
> client applications. Being able to group a subset of running RegionServers 
> and assign specific tables to it, provides a client application a level of 
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of 
> RegionServer groups and assigns tables to region servers based on groupings. 
> Load balancing will occur on a per group basis as well. 
> This is essentially a simplification of the approach taken in HBASE-4120. See 
> attached document.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218137#comment-16218137
 ] 

Hudson commented on HBASE-15631:


FAILURE: Integrated in Jenkins build HBase-1.5 #115 (See 
[https://builds.apache.org/job/HBase-1.5/115/])
Amend HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 
(apurtell: rev 089acc74dad0bd6368e4bb584fde2a84b8c8ab56)
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1-addendum.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19085) Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning

[ramkrishna.s.vasudevan (JIRA)]

ramkrishna.s.vasudevan created HBASE-19085:
--

 Summary: Fix findbug EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC warning
 Key: HBASE-19085
 URL: https://issues.apache.org/jira/browse/HBASE-19085
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0-alpha-4


Seems the recent commits have introduced a findbug warning.
'org.apache.hadoop.hbase.regionserver.MemStoreSizing overrides equals 
in MemStoreSize and may not be symmetric'.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218132#comment-16218132
 ] 

stack commented on HBASE-19074:
---

Pushed this addendum to branch-2 and master:

{code}
commit 43a8ac00158e92c3015af7753edd8e835dc6054b
Author: Michael Stack 
Date:   Tue Oct 24 22:40:30 2017 -0700

BASE-19074 Miscellaneous Observer cleanups; ADDEDNUM to fix FindBugs

diff --git 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
index cf2ef6fe60..557a61a49c 100644
--- 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
+++ 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
@@ -62,7 +62,7 @@ public class MemStoreSize {

   @Override
   public boolean equals(Object obj) {
-if (obj == null || !(obj instanceof MemStoreSize)) {
+if (obj == null || getClass() != obj.getClass()) {
   return false;
 }
 MemStoreSize other = (MemStoreSize) obj;
diff --git 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
index fade622251..b13201d4a2 100644
--- 
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
+++ 
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
@@ -82,7 +82,7 @@ public class MemStoreSizing extends MemStoreSize {

   @Override
   public boolean equals(Object obj) {
-if (obj == null || !(obj instanceof MemStoreSizing)) {
+if (obj == null || (getClass() != obj.getClass())) {
   return false;
 }
 MemStoreSizing other = (MemStoreSizing) obj;
{code}

Thanks [~chia7712]

> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch, 
> HBASE-19074.master.002.patch, HBASE-19074.master.003.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few 
> violations such as Store returning a MemStoreSize instance (which would let 
> coprocessors inc/dec MemStore size which would mess us up). This issue is 
> about cleaning these remainders up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore

[ramkrishna.s.vasudevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218128#comment-16218128
 ] 

ramkrishna.s.vasudevan commented on HBASE-18994:


Findbugs not from this patch. Ping for reviews.

> Decide if META/System tables should use Compacting Memstore or Default 
> Memstore
> ---
>
> Key: HBASE-18994
> URL: https://issues.apache.org/jira/browse/HBASE-18994
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18994.patch, HBASE-18994_1.patch, 
> HBASE-18994_2.patch, HBASE-18994_3.patch
>
>
> HBASE-18992 brought this topic. Currently META is also using Compacting 
> Memstore. We should decide if system tables can go with Default memstore only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18906) Provide Region#waitForFlushes API

[Anoop Sam John (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sam John updated HBASE-18906:
---
Description: 
Expose an API for the CPs to wait for all on going flushes in a Region. The API 
should support taking a time out.

Background
While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
issue is to see why they need them and whether alternate ways are possible. 
This seems to be too much internal stuff and a normal CP hook calling these 
would be dangerous.
If there are alternate ways for Phoenix not to use this and not landing in 
issues (As said by Andy) we should suggest/fix for them.

  was:
While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
issue is to see why they need them and whether alternate ways are possible. 
This seems to be too much internal stuff and a normal CP hook calling these 
would be dangerous.
If there are alternate ways for Phoenix not to use this and not landing in 
issues (As said by Andy) we should suggest/fix for them.


> Provide Region#waitForFlushes API
> -
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18906.patch
>
>
> Expose an API for the CPs to wait for all on going flushes in a Region. The 
> API should support taking a time out.
> Background
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218106#comment-16218106
 ] 

Hudson commented on HBASE-15631:


FAILURE: Integrated in Jenkins build HBase-1.4 #972 (See 
[https://builds.apache.org/job/HBase-1.4/972/])
Amend HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 
(apurtell: rev 11b7e1bc8cafca686d020b67239248f1347ad775)
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1-addendum.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-6721) RegionServer Group based Assignment

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218107#comment-16218107
 ] 

Hudson commented on HBASE-6721:
---

FAILURE: Integrated in Jenkins build HBase-1.4 #972 (See 
[https://builds.apache.org/job/HBase-1.4/972/])
Amend HBASE-15631 Backport Regionserver Groups (HBASE-6721) to branch-1 
(apurtell: rev 11b7e1bc8cafca686d020b67239248f1347ad775)
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/master/balancer/TestRSGroupBasedLoadBalancer.java
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java


> RegionServer Group based Assignment
> ---
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
>  Issue Type: New Feature
>  Components: regionserver
>Reporter: Francis Liu
>Assignee: Francis Liu
>  Labels: hbase-6721
> Fix For: 2.0.0
>
> Attachments: 6721-master-webUI.patch, HBASE-6721 
> GroupBasedLoadBalancer Sequence Diagram.xml, HBASE-6721-DesigDoc.pdf, 
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, 
> HBASE-6721_0.98_2.patch, HBASE-6721_10.patch, HBASE-6721_11.patch, 
> HBASE-6721_12.patch, HBASE-6721_13.patch, HBASE-6721_14.patch, 
> HBASE-6721_15.patch, HBASE-6721_8.patch, HBASE-6721_9.patch, 
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch, 
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch, 
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch, 
> HBASE-6721_94_7.patch, HBASE-6721_98_1.patch, HBASE-6721_98_2.patch, 
> HBASE-6721_hbase-6721_addendum.patch, HBASE-6721_trunk.patch, 
> HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch, 
> HBASE-6721_trunk2.patch, balanceCluster Sequence Diagram.svg, 
> hbase-6721-v15-branch-1.1.patch, hbase-6721-v16.patch, hbase-6721-v17.patch, 
> hbase-6721-v18.patch, hbase-6721-v19.patch, hbase-6721-v20.patch, 
> hbase-6721-v21.patch, hbase-6721-v22.patch, hbase-6721-v23.patch, 
> hbase-6721-v25.patch, hbase-6721-v26.patch, hbase-6721-v26_draft1.patch, 
> hbase-6721-v27.patch, hbase-6721-v27.patch, hbase-6721-v27.patch.txt, 
> hbase-6721-v28.patch, hbase-6721-v28.patch, hbase-6721-v29.patch, 
> immediateAssignments Sequence Diagram.svg, randomAssignment Sequence 
> Diagram.svg, retainAssignment Sequence Diagram.svg, roundRobinAssignment 
> Sequence Diagram.svg
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will 
> be serving out regions from a number of different tables owned by various 
> client applications. Being able to group a subset of running RegionServers 
> and assign specific tables to it, provides a client application a level of 
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of 
> RegionServer groups and assigns tables to region servers based on groupings. 
> Load balancing will occur on a per group basis as well. 
> This is essentially a simplification of the approach taken in HBASE-4120. See 
> attached document.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218101#comment-16218101
 ] 

stack commented on HBASE-19074:
---

Sorry about that [~chia7712] Thanks for spotting it. Let me fix.

> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch, 
> HBASE-19074.master.002.patch, HBASE-19074.master.003.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few 
> violations such as Store returning a MemStoreSize instance (which would let 
> coprocessors inc/dec MemStore size which would mess us up). This issue is 
> about cleaning these remainders up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18906) Provide Region#waitForFlushes API

[Anoop Sam John (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sam John updated HBASE-18906:
---
Summary: Provide Region#waitForFlushes API  (was: Investigate Phoenix 
usages of Region#waitForXXX APIs)

> Provide Region#waitForFlushes API
> -
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18906.patch
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218100#comment-16218100
 ] 

stack commented on HBASE-19048:
---

See this in patch  Threads.sleep(1000);

> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch, 
> HBASE-19048.master.002.patch, HBASE-19048.master.003.patch, 
> HBASE-19048.master.003.patch
>
>
> These are the ones in MasterObserver
> {code}
>   preAbortProcedure-  ProcedureExecutor
>   postGetProcedures- Procedure
>   postGetLocks - LockedResource
>   preRequestLock   - LockType
>   postRequestLock  - LockType
>   preLockHeartbeat - LockProcedure
>   postLockHeartbeat- LockProcedure
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19077:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
Release Note: Adds getOnlineRegions to the RegionCoprocessorEnvironment 
(Context) and ditto to RegionServerCoprocessorEnvironment. Allows Coprocessor 
get list of Regions online on the currently hosting RegionServer.
  Status: Resolved  (was: Patch Available)

Pushed to Master and branch-2.

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch, 
> HBASE-19077.master.002.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Anoop Sam John (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sam John updated HBASE-18906:
---
Attachment: HBASE-18906.patch

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18906.patch
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Anoop Sam John (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sam John updated HBASE-18906:
---
Status: Patch Available  (was: Open)

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18906.patch
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218090#comment-16218090
 ] 

stack commented on HBASE-19077:
---

.002 javadoc improvements via [~elserj]. This is what I will push.

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch, 
> HBASE-19077.master.002.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19077:
--
Attachment: HBASE-19077.master.002.patch

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch, 
> HBASE-19077.master.002.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218091#comment-16218091
 ] 

Anoop Sam John commented on HBASE-18906:


For flush if there is already a snapshot in progress, we will not take cur req.
Compaction do we have this way? I dont think so.   
So the plan here is to have a waitForFlushes(long timeout) API in Region

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218087#comment-16218087
 ] 

Anoop Sam John commented on HBASE-19048:


bq.One weird thing is necessity of a 1 second pause granting a permission in 
test. Cannot figure why needed here and no where else.
Which test case boss?

> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch, 
> HBASE-19048.master.002.patch, HBASE-19048.master.003.patch, 
> HBASE-19048.master.003.patch
>
>
> These are the ones in MasterObserver
> {code}
>   preAbortProcedure-  ProcedureExecutor
>   postGetProcedures- Procedure
>   postGetLocks - LockedResource
>   preRequestLock   - LockType
>   postRequestLock  - LockType
>   preLockHeartbeat - LockProcedure
>   postLockHeartbeat- LockProcedure
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18770) Remove bypass method in ObserverContext and implement the 'bypass' logic case by case

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218083#comment-16218083
 ] 

stack commented on HBASE-18770:
---

.001 is start. See edit of RegionObserver to see how it does bypass semantic 
per method-call. Unfortunately, I can't paint all methods w/ the one color; how 
bypass is done per method. Would appreciate a review. Next up is my making sure 
these bypasses all work, have test coverage, etc.

A CP can't bypass flush. I'm thinking that CP won't have enough info to block a 
flush and even then, it would have to schedule and then wait on completion 
before progressing.

A CP can 'cancel' a compaction by returning empty set of files to compact. This 
is how has always been.

> Remove bypass method in ObserverContext and implement the 'bypass' logic case 
> by case
> -
>
> Key: HBASE-18770
> URL: https://issues.apache.org/jira/browse/HBASE-18770
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18770.master.001.patch
>
>
> http://search-hadoop.com/m/HBase/YGbbXd0RDCIHSC1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups

[Chia-Ping Tsai (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218082#comment-16218082
 ] 

Chia-Ping Tsai commented on HBASE-19074:


It seems the patch you submit to trigger QA doesn't include the 
{{MemStoreSizing}}, so the findbugs doesn't complain. Do you mind pushing a 
addendum to handle the complain?
{quote}
Bug type EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC (click for details)
In class org.apache.hadoop.hbase.regionserver.MemStoreSizing
In method org.apache.hadoop.hbase.regionserver.MemStoreSizing.equals(Object)
Overrides org.apache.hadoop.hbase.regionserver.MemStoreSize.equals(Object)
At MemStoreSizing.java:[lines 85-89]
{quote}
see 
[here|https://builds.apache.org/job/PreCommit-HBASE-Build/9384/artifact/patchprocess/branch-findbugs-hbase-server-warnings.html]
 for more details.

> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch, 
> HBASE-19074.master.002.patch, HBASE-19074.master.003.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few 
> violations such as Store returning a MemStoreSize instance (which would let 
> coprocessors inc/dec MemStore size which would mess us up). This issue is 
> about cleaning these remainders up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18770) Remove bypass method in ObserverContext and implement the 'bypass' logic case by case

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-18770:
--
Attachment: HBASE-18770.master.001.patch

> Remove bypass method in ObserverContext and implement the 'bypass' logic case 
> by case
> -
>
> Key: HBASE-18770
> URL: https://issues.apache.org/jira/browse/HBASE-18770
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18770.master.001.patch
>
>
> http://search-hadoop.com/m/HBase/YGbbXd0RDCIHSC1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218077#comment-16218077
 ] 

stack commented on HBASE-19002:
---

Assigned you [~ted_yu] ... unassign if I have it wrong.

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reassigned HBASE-19002:
-

Assignee: Ted Yu

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Ted Yu
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18925) Need updated mockito for using java optional

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218068#comment-16218068
 ] 

Appy commented on HBASE-18925:
--

FIxed TestRpcScheduler. The issue was any(Foo.class) doesn't match null 
anymore. Only any() matches null.
>From mockito docs 
>(https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2)
{quote}
anyX() and any(SomeType.class) matchers now reject nulls and check type. This 
has been long waited feature, making Mockito syntax more intuitive. (In the 
following list T represents some type like Integer, List)

*  T any() will matches anything including null
* T anyT() /  any(Class) are aliases of  isA(T), will matches non-null 
object of given type. e.g. :
** int anyInt() won't match null (for Integers) anymore
** String anyString() won't match null (for Strings) anymore, and will check 
the object is indeed a String
** Map anyMap() won't match null (for Maps) anymore, and will check the 
object is indeed a Map
**  List anyListOf(Class) will match non-null List, and will check the 
object is indeed a List
{quote}

> Need updated mockito for using java optional
> 
>
> Key: HBASE-18925
> URL: https://issues.apache.org/jira/browse/HBASE-18925
> Project: HBase
>  Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18925.master.001.patch, 
> HBASE-18925.master.002.patch, HBASE-18925.master.002.patch, 
> HBASE-18925.master.003.patch, HBASE-18925.master.004.patch
>
>
> Came up when i was trying to test HBASE-18878.
> It kept failing because mock of RpcCall returned null where return type was 
> Optional.
> Instead, we want it to return Optional.empty(). 
> New mockito versions support this (and other java8 things) - 
> https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
> We use mockito-all which was last released in Dec2014. However, mockito-core 
> has had more than 50 releases after that 
> (https://mvnrepository.com/artifact/org.mockito/mockito-core). 
> We need to change our deps from mockito-all to mockito-core.
> However that comes with fair breakages, so this is not a simple task of 
> changing pom files.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18925) Need updated mockito for using java optional

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-18925:
-
Attachment: HBASE-18925.master.004.patch

> Need updated mockito for using java optional
> 
>
> Key: HBASE-18925
> URL: https://issues.apache.org/jira/browse/HBASE-18925
> Project: HBase
>  Issue Type: Improvement
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18925.master.001.patch, 
> HBASE-18925.master.002.patch, HBASE-18925.master.002.patch, 
> HBASE-18925.master.003.patch, HBASE-18925.master.004.patch
>
>
> Came up when i was trying to test HBASE-18878.
> It kept failing because mock of RpcCall returned null where return type was 
> Optional.
> Instead, we want it to return Optional.empty(). 
> New mockito versions support this (and other java8 things) - 
> https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
> We use mockito-all which was last released in Dec2014. However, mockito-core 
> has had more than 50 releases after that 
> (https://mvnrepository.com/artifact/org.mockito/mockito-core). 
> We need to change our deps from mockito-all to mockito-core.
> However that comes with fair breakages, so this is not a simple task of 
> changing pom files.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218058#comment-16218058
 ] 

stack commented on HBASE-19057:
---

bq. I've updated the release note with more details about the bug fix, I think 
it's enough.

It looks good.

bq. So let's commit the latest patch.v5 into branch HBASE-18410, and do the 
rebase ...

Yes. No harm in doing concurrently what [~Apache9] said of hacking up a patch 
of all here to run against master in the mean time (I think thats what he 
suggests above).

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19048:
--
Attachment: HBASE-19048.master.003.patch

Retry

> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch, 
> HBASE-19048.master.002.patch, HBASE-19048.master.003.patch, 
> HBASE-19048.master.003.patch
>
>
> These are the ones in MasterObserver
> {code}
>   preAbortProcedure-  ProcedureExecutor
>   postGetProcedures- Procedure
>   postGetLocks - LockedResource
>   preRequestLock   - LockType
>   postRequestLock  - LockType
>   preLockHeartbeat - LockProcedure
>   postLockHeartbeat- LockProcedure
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218056#comment-16218056
 ] 

stack commented on HBASE-19048:
---

Failed w/ this:
{code}
23:21:13 /usr/share/maven/bin/mvn clean install -DskipTests -DHBasePatchProcess 
-Dhadoop-three.version=3.0.0-alpha4 -Dhadoop.profile=3.0 > 
/testptch/patchprocess/patch-javac-3.0.0-alpha4.txt 2>&1
23:27:30 FATAL: command execution failed
23:27:30 Command close created at
23:27:30at hudson.remoting.Command.(Command.java:60)
23:27:30at 
hudson.remoting.Channel$CloseCommand.(Channel.java:1132)
23:27:30at 
hudson.remoting.Channel$CloseCommand.(Channel.java:1130)
23:27:30at hudson.remoting.Channel.close(Channel.java:1290)
23:27:30at hudson.remoting.Channel.close(Channel.java:1272)
23:27:30at 
hudson.remoting.Channel$CloseCommand.execute(Channel.java:1137)
23:27:30 Caused: hudson.remoting.Channel$OrderlyShutdown
23:27:30at 
hudson.remoting.Channel$CloseCommand.execute(Channel.java:1138)
23:27:30at hudson.remoting.Channel$1.handle(Channel.java:535)
23:27:30at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:83)
23:27:30 Caused: java.io.IOException: Backing channel 'H4' is disconnected.
23:27:30at 
hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:192)
23:27:30at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:257)
23:27:30at com.sun.proxy.$Proxy129.isAlive(Unknown Source)
23:27:30at 
hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:1138)
23:27:30at 
hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:1130)
23:27:30at 
hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:155)
23:27:30at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:109)
23:27:30at 
hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
23:27:30at 
hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
23:27:30at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:736)
23:27:30at hudson.model.Build$BuildExecution.build(Build.java:206)
23:27:30at hudson.model.Build$BuildExecution.doRun(Build.java:163)
23:27:30at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:496)
23:27:30at hudson.model.Run.execute(Run.java:1737)
23:27:30at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
23:27:30at 
hudson.model.ResourceController.execute(ResourceController.java:97)
23:27:30at hudson.model.Executor.run(Executor.java:419)
23:27:30 Build step 'Execute shell' marked build as failure
{code}

Retry

> Cleanup MasterObserver hooks which takes IA private params
> --
>
> Key: HBASE-19048
> URL: https://issues.apache.org/jira/browse/HBASE-19048
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19048.master.001.patch, 
> HBASE-19048.master.002.patch, HBASE-19048.master.003.patch
>
>
> These are the ones in MasterObserver
> {code}
>   preAbortProcedure-  ProcedureExecutor
>   postGetProcedures- Procedure
>   postGetLocks - LockedResource
>   preRequestLock   - LockType
>   postRequestLock  - LockType
>   preLockHeartbeat - LockProcedure
>   postLockHeartbeat- LockProcedure
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18410) FilterList Improvement.

[Zheng Hu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zheng Hu updated HBASE-18410:
-
Release Note: 
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  

The primary bug  fixes are : 
1. For sub-filter in FilterList with MUST_PASS_ONE, if previous 
filterKeyValue() of sub-filter returns NEXT_COL, we cannot make sure that the 
next cell will be the first cell in next column, because FilterList choose the 
minimal forward step among sub-filters, and it may return a SKIP. so here we 
add an extra check to ensure that the next cell will match preivous return code 
for sub-filters. 
2. Previous logic about transforming cell of FilterList is incorrect, we should 
set the previous transform result (rather than the given cell in question) as 
the initial vaule of transform cell before call filterKeyValue() of FilterList.
3. Handle the ReturnCodes which the previous code did not handle. 

About code refactor, we divided the FilterList into two separated sub-classes: 
FilterListWithOR and FilterListWithAND,  The FilterListWithOR has been 
optimised to choose the next minimal step to seek cell rather than SKIP cell 
one by one, and the FilterListWithAND  has been optimised to choose the next 
maximal key to seek among sub-filters in filter list. All in all, The code in 
FilterList is clean and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.

  was:
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  

The primary bug  fixes are : 
1. For sub-filter in FilterList with MUST_PASS_ONE, if previous 
filterKeyValue() of sub-filter returns NEXT_COL, we cannot make sure that the 
next cell will be the first cell in next column, because FilterList choose the 
minimal forward step among sub-filters, and it may return a SKIP. so here we 
add an extra check to ensure that the next cell will match preivous return code 
for sub-filters. 
2. Previous logic about transforming cell of FilterList is incorrect, we should 
set the previous transform result as the initial vaule of transform cell before 
call filterKeyValue() of FilterList rather than the given cell in question.
3. Handle all exist ReturnCodes which the previous code did not. 

About code refactor, we divided the FilterList into two separated sub-classes: 
FilterListWithOR and FilterListWithAND,  The FilterListWithOR has been 
optimised to choose the next minimal step to seek cell rather than SKIP cell 
one by one, and the FilterListWithAND  has been optimised to choose the next 
maximal key to seek among sub-filters in filter list. All in all, The code in 
FilterList is clean and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.


> FilterList  Improvement. 
> -
>
> Key: HBASE-18410
> URL: https://issues.apache.org/jira/browse/HBASE-18410
> Project: HBase
>  Issue Type: Umbrella
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-alpha-4
>
>
> FilterList.java is complex now, and we have found some improvements for it.  
> So create an issue to address it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Zheng Hu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218055#comment-16218055
 ] 

Zheng Hu commented on HBASE-19057:
--

bq. Can fix the mis-comment on commit. 
I've fixed the comment what Ted point out in the latest patch.v5 , you can see 
that. 
bq. Does the release note here have enough on what is different between hbase1 
and hbase2? 
I've updated the release note with more details about the bug fix, I think it's 
enough. 

So let's commit the latest patch.v5 into branch HBASE-18410, and do the rebase 
... 




> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-16885) Deprecate public classes which are removed in 2.0

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-16885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu resolved HBASE-16885.

Resolution: Won't Fix

There have been many changes in API, making this obsolete.

> Deprecate public classes which are removed in 2.0
> -
>
> Key: HBASE-16885
> URL: https://issues.apache.org/jira/browse/HBASE-16885
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
> Attachments: phoenix-compile-against-2.0.txt
>
>
> I tried to compile master branch of Phoenix against 2.0-SNAPSHOT and observed 
> some compilation errors.
> /phoenix/phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexStoreFileScanner.java:[31,54]
>  cannot find symbol
>   symbol:   class Reader
>   location: class org.apache.hadoop.hbase.regionserver.StoreFile
> /phoenix/phoenix-core/src/main/java/org/apache/phoenix/mapreduce/MultiHfileOutputFormat.java:[300,16]
>  cannot find symbol
>   symbol:   class Writer
>   location: class org.apache.hadoop.hbase.regionserver.StoreFile
> The above inner classes of StoreFile are marked public as of branch-1.
> We should deprecate them in 1.x release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18410) FilterList Improvement.

[Zheng Hu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zheng Hu updated HBASE-18410:
-
Release Note: 
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  

The primary bug  fixes are : 
1. For sub-filter in FilterList with MUST_PASS_ONE, if previous 
filterKeyValue() of sub-filter returns NEXT_COL, we cannot make sure that the 
next cell will be the first cell in next column, because FilterList choose the 
minimal forward step among sub-filters, and it may return a SKIP. so here we 
add an extra check to ensure that the next cell will match preivous return code 
for sub-filters. 
2. Previous logic about transforming cell of FilterList is incorrect, we should 
set the previous transform result as the initial vaule of transform cell before 
call filterKeyValue() of FilterList rather than the given cell in question.
3. Handle all exist ReturnCodes which the previous code did not. 

About code refactor, we divided the FilterList into two separated sub-classes: 
FilterListWithOR and FilterListWithAND,  The FilterListWithOR has been 
optimised to choose the next minimal step to seek cell rather than SKIP cell 
one by one, and the FilterListWithAND  has been optimised to choose the next 
maximal key to seek among sub-filters in filter list. All in all, The code in 
FilterList is clean and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.

  was:
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  The primary bug  fix are : 
FilterList with MUST_PASS_ONE 

we divided the FilterList into two separated sub-classes: FilterListWithOR and 
FilterListWithAND,  The FilterListWithOR has been optimised to choose the next 
minimal step to seek cell rather than SKIP cell one by one, and the 
FilterListWithAND  has been optimised to choose the next maximal key to seek 
among sub-filters in filter list. All in all, The code in FilterList is clean 
and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.


> FilterList  Improvement. 
> -
>
> Key: HBASE-18410
> URL: https://issues.apache.org/jira/browse/HBASE-18410
> Project: HBase
>  Issue Type: Umbrella
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-alpha-4
>
>
> FilterList.java is complex now, and we have found some improvements for it.  
> So create an issue to address it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18410) FilterList Improvement.

[Zheng Hu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zheng Hu updated HBASE-18410:
-
Release Note: 
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  The primary bug  fix are : 
FilterList with MUST_PASS_ONE 

we divided the FilterList into two separated sub-classes: FilterListWithOR and 
FilterListWithAND,  The FilterListWithOR has been optimised to choose the next 
minimal step to seek cell rather than SKIP cell one by one, and the 
FilterListWithAND  has been optimised to choose the next maximal key to seek 
among sub-filters in filter list. All in all, The code in FilterList is clean 
and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.

  was:
In this task, we fixed all existing bugs in FilterList, and did the code 
refactor which ensured interface compatibility .  we divided the FilterList 
into two separated sub-classes: FilterListWithOR and FilterListWithAND,  The 
FilterListWithOR has been optimised to choose the next minimal step to seek 
cell rather than SKIP cell one by one, and the FilterListWithAND  has been 
optimised to choose the next maximal key to seek among sub-filters in filter 
list. All in all, The code in FilterList is clean and easier to follow now.

Note that ReturnCode NEXT_ROW has been redefined as skipping to next row in 
current family,   not to next row in all family. it’s more reasonable, because 
ReturnCode is a concept in store level, not in region level.


> FilterList  Improvement. 
> -
>
> Key: HBASE-18410
> URL: https://issues.apache.org/jira/browse/HBASE-18410
> Project: HBase
>  Issue Type: Umbrella
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-alpha-4
>
>
> FilterList.java is complex now, and we have found some improvements for it.  
> So create an issue to address it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218043#comment-16218043
 ] 

Hadoop QA commented on HBASE-19077:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  3m 
43s{color} | {color:blue} Docker mode activated. {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:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
58s{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:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
46s{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}  0m 
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
22s{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 
47s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
48m 29s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}122m 
35s{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}195m 23s{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-19077 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893835/HBASE-19077.master.001.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 5cdda0260c1c 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26 
18:04:35 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 / eee3b0180e |
| Default Java | 1.8.0_141 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9391/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9391/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: 

[jira] [Updated] (HBASE-19065) HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-19065:
---
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-alpha-4

> HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
> 
>
> Key: HBASE-19065
> URL: https://issues.apache.org/jira/browse/HBASE-19065
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-alpha-4
>
> Attachments: 19065.v1.txt, 19065.v2.txt, 19065.v2.txt
>
>
> When I was debugging bulk load failure, I saw the following in region server 
> log:
> {code}
> 2017-10-17 23:05:28,795 DEBUG 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] regionserver.HRegion: NOT 
> flushing memstore for region mx_, 
> f449669a8b0341e4edbd2ebdacc72094f449669a8b0341e4edbd2ebdacc7209420150711,1504909319142.52d496ba39036e0c2cc9522895ad438f.,
>  flushing=true, writesEnabled=true
> 2017-10-17 23:05:28,796 ERROR 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] 
> access.SecureBulkLoadEndpoint: Failed to complete bulk load
> java.io.IOException: Could not bulk load with an assigned sequential ID 
> because the flush didn't run. Reason for not flushing: Not flushing since 
> already flushing
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:5282)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:292)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:275)
> {code}
> There was concurrent flush which got misinterpreted by bulkLoadHFiles().
> HRegion#bulkLoadHFiles() should wait for the concurrent flush to complete.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19065) HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218031#comment-16218031
 ] 

Hudson commented on HBASE-19065:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3944 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3944/])
HBASE-19065 HRegion#bulkLoadHFiles() should wait for concurrent (tedyu: rev 
3cced094c57d7ecaf4f5b22a01cda58294595ced)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java


> HRegion#bulkLoadHFiles() should wait for concurrent Region#flush() to finish
> 
>
> Key: HBASE-19065
> URL: https://issues.apache.org/jira/browse/HBASE-19065
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 19065.v1.txt, 19065.v2.txt, 19065.v2.txt
>
>
> When I was debugging bulk load failure, I saw the following in region server 
> log:
> {code}
> 2017-10-17 23:05:28,795 DEBUG 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] regionserver.HRegion: NOT 
> flushing memstore for region mx_, 
> f449669a8b0341e4edbd2ebdacc72094f449669a8b0341e4edbd2ebdacc7209420150711,1504909319142.52d496ba39036e0c2cc9522895ad438f.,
>  flushing=true, writesEnabled=true
> 2017-10-17 23:05:28,796 ERROR 
> [B.defaultRpcServer.handler=0,queue=0,port=16020] 
> access.SecureBulkLoadEndpoint: Failed to complete bulk load
> java.io.IOException: Could not bulk load with an assigned sequential ID 
> because the flush didn't run. Reason for not flushing: Not flushing since 
> already flushing
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.bulkLoadHFiles(HRegion.java:5282)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:292)
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint$1.run(SecureBulkLoadEndpoint.java:275)
> {code}
> There was concurrent flush which got misinterpreted by bulkLoadHFiles().
> HRegion#bulkLoadHFiles() should wait for the concurrent flush to complete.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19018) Use of hadoop internals that require bouncycastle should declare bouncycastle dependency

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218032#comment-16218032
 ] 

Hudson commented on HBASE-19018:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3944 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3944/])
HBASE-19018 tests that need bouncycastle must delcare dependency on it. 
(busbey: rev 9353c59a99f914716a227a1a7a2d099f92e0d06c)
* (edit) hbase-endpoint/pom.xml


> Use of hadoop internals that require bouncycastle should declare bouncycastle 
> dependency
> 
>
> Key: HBASE-19018
> URL: https://issues.apache.org/jira/browse/HBASE-19018
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, test
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19018.0.patch, HBASE-19018.1.patch
>
>
> The tests for HBASE-15806 rely on a Hadoop internal class, 
> {{KeyStoreTestUtil}}, which in turn relies on the Bouncycastle library for 
> certificate generation.
> when building / running with Hadoop 2.7.1, we accidentally get a bouncycastle 
> implementation via a transitive dependency of {{hadoop-minikdc}}. When 
> attempting to run against Hadoop 3.0.0-alpha4 and 3.0.0-beta1 (and presumably 
> future Hadoop 3.y releases), this bouncycastle jar is no longer pulled in and 
> we fail with a CNFE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19073) Cleanup CoordinatedStateManager

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19073:
-
   Resolution: Fixed
Fix Version/s: 2.0.0-alpha-4
   Status: Resolved  (was: Patch Available)

> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19073.master.001.patch, 
> HBASE-19073.master.002.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to 
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19073) Cleanup CoordinatedStateManager

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218028#comment-16218028
 ] 

Appy commented on HBASE-19073:
--

Pushed to master and branch-2.
Thanks for the review [~stack].


> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19073.master.001.patch, 
> HBASE-19073.master.002.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to 
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18905) Allow CPs to request flush on Region and know the completion of the requested flush

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-18905:
--
Attachment: HBASE-18905-v1.patch

Rebase and address the comments on rb.

> Allow CPs to request flush on Region and know the completion of the requested 
> flush
> ---
>
> Key: HBASE-18905
> URL: https://issues.apache.org/jira/browse/HBASE-18905
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18905-v1.patch, HBASE-18905.patch, 
> HBASE-18905.patch
>
>
> Follow up for HBASE-18183
> As per that Jira, we keep only requestCompaction API in Region.  We did not 
> have any such for flush in Region.  Only API which was there is a flush which 
> will block the callee unless flush is done. This issue has to tacke
> 1. Decide whether we need a requestFlush in Region and if so add
> 2. Whether the requestCompaction (And requestFlush too) should return a 
> Future?  Right now the former do  not return any but allow to pass a 
> CompactionLifeCycleTracker which will get notified on start and end of 
> compaction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218020#comment-16218020
 ] 

stack edited comment on HBASE-19057 at 10/25/17 3:01 AM:
-

Don't bother with the VOTE thread I'd say. Let me add to the end of the DISCUSS 
that we'll just merge, not VOTE. Does the release note here have enough on what 
is different between hbase1 and hbase2?


was (Author: stack):
Don't bother with the VOTE thread. Let me add to the end of the DISCUSS that 
we'll just merge, not VOTE.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218020#comment-16218020
 ] 

stack commented on HBASE-19057:
---

Don't bother with the VOTE thread. Let me add to the end of the DISCUSS that 
we'll just merge, not VOTE.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218015#comment-16218015
 ] 

Duo Zhang commented on HBASE-19057:
---

[~openinx] Let's commit the patch here. And then I will do a final rebase. We 
can then attach a dumb patch here to just trigger a pre commit to see if 
everything is OK.Then we can start the vote thread in the dev list to see if we 
can get enough +1s. I think it is enough, [~stack] [~anoopsamjohn] [~tedyu] and 
me.

Thanks.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218012#comment-16218012
 ] 

stack commented on HBASE-19057:
---

[~openinx] Push. Can fix the mis-comment on commit. If [~Apache9] can't do it, 
just say and I can.

When we going to do the merge!

Thanks.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19073) Cleanup CoordinatedStateManager

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218007#comment-16218007
 ] 

Hadoop QA commented on HBASE-19073:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  1m 
36s{color} | {color:blue} Docker mode activated. {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 26 new or modified test 
files. {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}  5m 
 0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  5m 
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  4m 
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 11m 
20s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  4m 
29s{color} | {color:green} master passed {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}  5m 
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  6m 
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  6m 
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  5m 
 8s{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}  5m 
22s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
56m 25s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  4m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}184m 
43s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
26s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}294m 54s{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-19073 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893691/HBASE-19073.master.002.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux e5d31fe8d0e0 3.13.0-119-generic #166-Ubuntu SMP Wed May 3 
12:18:55 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 / eee3b0180e |
| Default Java | 1.8.0_141 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9390/testReport/ |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9390/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message 

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Ted Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218004#comment-16218004
 ] 

Ted Yu commented on HBASE-19057:


I have no other comment for this JIRA.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19048) Cleanup MasterObserver hooks which takes IA private params

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218000#comment-16218000
 ] 

Hadoop QA commented on HBASE-19048:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  3m 
19s{color} | {color:blue} Docker mode activated. {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:green}+1{color} | {color:green} mvninstall {color} | {color:green}  8m 
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  9m 
32s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m  
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  8m 
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
41s{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}  7m 
26s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
85m 31s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m  
4s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}181m 25s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
58s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}305m 10s{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-19048 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893802/HBASE-19048.master.003.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 5fcc76d26e3a 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26 
18:04:35 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 / eee3b0180e |
| Default Java | 1.8.0_141 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9389/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9389/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9389/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Cleanup MasterObserver hooks which takes IA private params
> --

[jira] [Commented] (HBASE-19054) Switch precommit docker image to one based on maven images

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217999#comment-16217999
 ] 

Duo Zhang commented on HBASE-19054:
---

Belated. +1. Nice simplification.

And what is the multi-jdk issue? On branch-1 or before we just both install 
jdk7 and jdk8, no other operations I think. But maybe a difference is that we 
used to install jdk7 first and then jdk8, if we based on maven:3.5-jdk8 then 
jdk7 will come after jdk8. Not sure if this will be an issue. I think we could 
have a try? [~mdrob].

Thanks.

> Switch precommit docker image to one based on maven images
> --
>
> Key: HBASE-19054
> URL: https://issues.apache.org/jira/browse/HBASE-19054
> Project: HBase
>  Issue Type: Bug
>  Components: build, community
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19054.patch, HBASE-19054.v2.patch
>
>
> In HBASE-19042 we discuss moving to a maven-based image for docker instead of 
> going through gymnastics ourselves. We got a short term fix in there, but 
> let's do the bulk of the cleanup here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217995#comment-16217995
 ] 

Guanghao Zhang commented on HBASE-16868:


bq. if I create a peer with no namespace/table, we will set replicate_all flag 
automatically?
Yes.
bq. And then if you add namespace/table to this peer, the operation will fail 
as you need to manually set the replicate_all flag to false first?
Yes. Need use "set_peer_replicate_all '1', false" first. Then append namespace 
or tablecfs to the peer.
bq. what is the behavior for an empty peer with a false replicate_all flag
If the replicate_all flag is false and no namespace/tablecfs config, the peer 
will replicate nothing.
bq. is it allowed to set replicate_all flag to true for a peer which already 
has namespace/table
Not allowed. It will throw new ReplicationException("Need clean namespaces or 
table-cfs config fisrtly when you want replicate all cluster").

bq. But I think you need to fix the rubocop and ruby-lint violations
I open a issue HBASE-18956  for this. Let me try to fix more warnings.

bq. The only concern for me is that we need to give a very clear behavior, and 
also the best practice on how to config a peer.
I will update the release note more clearly. Thanks.

> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Zheng Hu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zheng Hu updated HBASE-19057:
-
Attachment: HBASE-19057-HBASE-18410.v5.patch

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Zheng Hu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217993#comment-16217993
 ] 

Zheng Hu commented on HBASE-19057:
--

[~tedyu]

bq. Can you add comment explaining why NEXT_ROW would be treated the same as 
NEXT_COL ?
I think the javadoc of FilterListWithOR#mergeReturnCode have a good explanation 
about this.  
{code}
   * FilterList with MUST_PASS_ONE choose the minimal forward step among 
sub-filter in filter list.
   * Let's call it: The Minimal Step Rule. So if filter-A in filter list return 
INCLUDE and filter-B
   * in filter list return INCLUDE_AND_NEXT_COL, then the filter list should 
return INCLUDE. For
   * SEEK_NEXT_USING_HINT, it's more special, because we do not know how far it 
will forward, so we
   * use SKIP by default.
{code}

bq. Comment w.r.t. return value doesn't match the actual value.
Thanks for the check, Will update it in patch.v5, just  typo fix, no other code 
change. 

So if no other concerns, Can I  commit it to branch HBASE-18410 ? after that, 
we can rebase master ... 





> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217984#comment-16217984
 ] 

Duo Zhang commented on HBASE-16868:
---

So in general, if I create a peer with no namespace/table, we will set 
replicate_all flag automatically? And then if you add namespace/table to this 
peer, the operation will fail as you need to manually set the replicate_all 
flag to false first? Then what is the behavior for an empty peer with a false 
replicate_all flag? And is it allowed to set replicate_all flag to true for a 
peer which already has namespace/table?

The code is fine, and I see you add UTs for the new feature, good. But I think 
you need to fix the rubocop and ruby-lint violations. The only concern for me 
is that we need to give a very clear behavior, and also the best practice on 
how to config a peer.

Thanks.

> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217980#comment-16217980
 ] 

Guanghao Zhang commented on HBASE-16868:


ping [~ashish singhi] for reviewing.

> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-16868) Add a replicate_all flag to avoid misuse the namespaces and table-cfs config of replication peer

[Guanghao Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-16868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217972#comment-16217972
 ] 

Guanghao Zhang commented on HBASE-16868:


ping [~Apache9] for reviewing.

> Add a replicate_all flag to avoid misuse the namespaces and table-cfs config 
> of replication peer
> 
>
> Key: HBASE-16868
> URL: https://issues.apache.org/jira/browse/HBASE-16868
> Project: HBase
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-16868.master.001.patch, 
> HBASE-16868.master.002.patch, HBASE-16868.master.003.patch, 
> HBASE-16868.master.004.patch, HBASE-16868.master.005.patch, 
> HBASE-16868.master.006.patch, HBASE-16868.master.007.patch
>
>
> First add a new peer by shell cmd.
> {code}
> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase".
> {code}
> If we don't set namespaces and table cfs in peer config. It means replicate 
> all tables to the peer cluster.
> Then append a table to the peer config.
> {code}
> append_peer_tableCFs '1', {"table1" => []}
> {code}
> Then this peer will only replicate table1 to the peer cluster. It changes to 
> replicate only one table from replicate all tables in the cluster. It is very 
> easy to misuse in production cluster. So we should avoid appending table to a 
> peer which replicates all table.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19018) Use of hadoop internals that require bouncycastle should declare bouncycastle dependency

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217970#comment-16217970
 ] 

Hudson commented on HBASE-19018:


FAILURE: Integrated in Jenkins build HBase-2.0 #744 (See 
[https://builds.apache.org/job/HBase-2.0/744/])
HBASE-19018 tests that need bouncycastle must delcare dependency on it. 
(busbey: rev 3f29498d19af7a687bea664cfb0190e1e98188e0)
* (edit) hbase-endpoint/pom.xml


> Use of hadoop internals that require bouncycastle should declare bouncycastle 
> dependency
> 
>
> Key: HBASE-19018
> URL: https://issues.apache.org/jira/browse/HBASE-19018
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, test
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19018.0.patch, HBASE-19018.1.patch
>
>
> The tests for HBASE-15806 rely on a Hadoop internal class, 
> {{KeyStoreTestUtil}}, which in turn relies on the Bouncycastle library for 
> certificate generation.
> when building / running with Hadoop 2.7.1, we accidentally get a bouncycastle 
> implementation via a transitive dependency of {{hadoop-minikdc}}. When 
> attempting to run against Hadoop 3.0.0-alpha4 and 3.0.0-beta1 (and presumably 
> future Hadoop 3.y releases), this bouncycastle jar is no longer pulled in and 
> we fail with a CNFE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-15631:
---
Attachment: HBASE-15631-branch-1-addendum.patch

Attaching an addendum I just committed:

- Restore missing unit in TestRSGroupBasedLoadBalancer
- Restore missing hunk in RSGroupBasedLoadBalancer

All RSGroups unit tests continue to pass after this change. (Tested 10 
iterations.)

When porting back the changes committed to branch-1 and branch-1.4 to our 
internal tree based on 1.3 I found a dropped delta (still in git stash, FWIW). 

> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1-addendum.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19054) Switch precommit docker image to one based on maven images

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217971#comment-16217971
 ] 

Hudson commented on HBASE-19054:


FAILURE: Integrated in Jenkins build HBase-2.0 #744 (See 
[https://builds.apache.org/job/HBase-2.0/744/])
HBASE-19054 switch precommit image to one from maven (mdrob: rev 
9f2f2db91c2ede894a86d4d5af21b1705dc4d3c3)
* (edit) dev-support/docker/Dockerfile


> Switch precommit docker image to one based on maven images
> --
>
> Key: HBASE-19054
> URL: https://issues.apache.org/jira/browse/HBASE-19054
> Project: HBase
>  Issue Type: Bug
>  Components: build, community
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19054.patch, HBASE-19054.v2.patch
>
>
> In HBASE-19042 we discuss moving to a maven-based image for docker instead of 
> going through gymnastics ourselves. We got a short term fix in there, but 
> let's do the bulk of the cleanup here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (HBASE-19047) CP exposed Scanner types should not extend Shipper

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-19047:
--
Comment: was deleted

(was: Is it always safe to cast RegionScanner to Shipper? Is RegionScanner 
something that we expect to be pluggable? I'm missing a lot of context here, 
but that part of the patch stuck out to me.)

> CP exposed Scanner types should not extend Shipper
> --
>
> Key: HBASE-19047
> URL: https://issues.apache.org/jira/browse/HBASE-19047
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19047.patch
>
>
> Shipper is a IA.Private interface and very much internal.. 
> Right now CP exposed RegionScanner is extending this and so exposing the 
> shipped() method. This by mistake is called, can harm the correctness of the 
> cells in the Results.
> preScannerOpen() allowing to return a new Scanner is also problematic now.  
> This can allow users to create a Region scanner from Region and then wrap it 
> and return back (Well same can be done by postScannerOpen also), it can so 
> happen that the wrapper is not implementing the shipped() properly.  In any 
> way exposing the shipped () is problematic.
> Solution Steps
> 1. Remove preScannerOpen() , the use case I can think of is wrapping the 
> original scanner. The original scanner can be created by Region.getScanner 
> way only..  May be no need to remove this hook.  Just remove the ability for 
> it to return a RegionScanner instance.  Call this with the Scan object and 
> the CP can change the Scan object if they want.
> 2. Let RegionScanner not extending Shipper but only RegionScannerImpl 
> implements this
> 3. We have ref to the RegionScanner created by core and let that be used by 
> RegionScannerShippedCallBack when the post hook doing a wrap.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19047) CP exposed Scanner types should not extend Shipper

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217966#comment-16217966
 ] 

Mike Drob commented on HBASE-19047:
---

Is it always safe to cast RegionScanner to Shipper? Is RegionScanner something 
that we expect to be pluggable? I'm missing a lot of context here, but that 
part of the patch stuck out to me.

> CP exposed Scanner types should not extend Shipper
> --
>
> Key: HBASE-19047
> URL: https://issues.apache.org/jira/browse/HBASE-19047
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19047.patch
>
>
> Shipper is a IA.Private interface and very much internal.. 
> Right now CP exposed RegionScanner is extending this and so exposing the 
> shipped() method. This by mistake is called, can harm the correctness of the 
> cells in the Results.
> preScannerOpen() allowing to return a new Scanner is also problematic now.  
> This can allow users to create a Region scanner from Region and then wrap it 
> and return back (Well same can be done by postScannerOpen also), it can so 
> happen that the wrapper is not implementing the shipped() properly.  In any 
> way exposing the shipped () is problematic.
> Solution Steps
> 1. Remove preScannerOpen() , the use case I can think of is wrapping the 
> original scanner. The original scanner can be created by Region.getScanner 
> way only..  May be no need to remove this hook.  Just remove the ability for 
> it to return a RegionScanner instance.  Call this with the Scan object and 
> the CP can change the Scan object if they want.
> 2. Let RegionScanner not extending Shipper but only RegionScannerImpl 
> implements this
> 3. We have ref to the RegionScanner created by core and let that be used by 
> RegionScannerShippedCallBack when the post hook doing a wrap.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache based on table name

[Zach York (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217955#comment-16217955
 ] 

Zach York commented on HBASE-18624:
---

[~anoop.hbase] [~chia7712] I have updated the RB and patch. Can you take 
another look when you get a chance?

> Added support for clearing BlockCache based on table name
> -
>
> Key: HBASE-18624
> URL: https://issues.apache.org/jira/browse/HBASE-18624
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Ajay Jadhav
>Assignee: Zach York
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-18624.branch-1.001.patch, 
> HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, 
> HBASE-18624.master.003.patch, HBASE-18624.master.004.patch
>
>
> Bulk loading the primary HBase cluster triggers a lot of compactions 
> resulting in archival/ creation
> of multiple HFiles. This process will cause a lot of items to become stale in 
> replica’s BlockCache.
> This patch will help users to clear the block cache for a given table by 
> either using shell or API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18232) Add variable size chunks to the MSLAB

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217898#comment-16217898
 ] 

Hadoop QA commented on HBASE-18232:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  3m 
25s{color} | {color:blue} Docker mode activated. {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 3 new or modified test 
files. {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 
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
45s{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:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
53s{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}  0m 
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
 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} 
49m 55s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}118m 
36s{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}191m 43s{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-18232 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893794/HBASE-18232-V07.patch 
|
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux c10f5a86f4e8 3.13.0-119-generic #166-Ubuntu SMP Wed May 3 
12:18:55 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 / eee3b0180e |
| Default Java | 1.8.0_141 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9388/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9388/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Add variable size chunks to the MSLAB
> -
>
> Key: HBASE-18232
> URL: https://issues.apache.org/jira/browse/HBASE-18232
> Project: HBase
>  Issue 

[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217876#comment-16217876
 ] 

Hadoop QA commented on HBASE-13346:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  2m 
23s{color} | {color:blue} Docker mode activated. {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 17 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  1m 
 8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  6m 
57s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
22s{color} | {color:green} master passed {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 
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  1m 
 6s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red}  0m  
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git 
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply 
{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} 
44m 44s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
37s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 90m 
46s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m 
41s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  4m 
21s{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
58s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}183m 42s{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-13346 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893795/HBASE-13346.master.009.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux cc8f5d40b0e4 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 

[jira] [Commented] (HBASE-18994) Decide if META/System tables should use Compacting Memstore or Default Memstore

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217857#comment-16217857
 ] 

Hadoop QA commented on HBASE-18994:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m 
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  6m 
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  7m 
 6s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red}  3m 
14s{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
8s{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} mvneclipse {color} | {color:green}  0m 
30s{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}  5m 
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} 
58m 59s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}150m 
49s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
29s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}259m 35s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-18994 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893773/HBASE-18994_3.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 9ea21e39bc79 3.13.0-119-generic #166-Ubuntu SMP Wed May 3 
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 3cced09 |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
| findbugs | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9384/artifact/patchprocess/branch-findbugs-hbase-server-warnings.html
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9384/testReport/ |
| modules | C: hbase-server U: 

[jira] [Commented] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217841#comment-16217841
 ] 

stack commented on HBASE-19002:
---

On phoenix use of hbase coprocessors, 
https://docs.google.com/document/d/10cabwp_aR3OmpHVoeh544YLC3KwqMD9KiTIrHZAmfec/edit

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217831#comment-16217831
 ] 

stack commented on HBASE-19077:
---

.001 Adds getOnlineRegions to RegionCPE and to RegionServerCPE (changed name of 
read-only Interface from ImmutableOnlineRegions to OnlineRegions).

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19077:
--
Status: Patch Available  (was: Open)

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19077) Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19077:
--
Attachment: HBASE-19077.master.001.patch

> Have Region*CoprocessorEnvironment provide an ImmutableOnlineRegions
> 
>
> Key: HBASE-19077
> URL: https://issues.apache.org/jira/browse/HBASE-19077
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19077.master.001.patch
>
>
> This is about restoring some of the hbase1 parity... You used to be able to 
> get list of Region on the local server and talk to them directly.
> Suggested by [~anoop.hbase] up in review. Makes sense.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[Ted Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217829#comment-16217829
 ] 

Ted Yu commented on HBASE-19002:


I am still warming up to the many changes in coprocessor.

I also need to get familiar with, say Phoenix, uses related hooks.

This may take some time.

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18624) Added support for clearing BlockCache based on table name

[Zach York (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zach York updated HBASE-18624:
--
Attachment: HBASE-18624.master.004.patch

> Added support for clearing BlockCache based on table name
> -
>
> Key: HBASE-18624
> URL: https://issues.apache.org/jira/browse/HBASE-18624
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Ajay Jadhav
>Assignee: Zach York
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-18624.branch-1.001.patch, 
> HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, 
> HBASE-18624.master.003.patch, HBASE-18624.master.004.patch
>
>
> Bulk loading the primary HBase cluster triggers a lot of compactions 
> resulting in archival/ creation
> of multiple HFiles. This process will cause a lot of items to become stale in 
> replica’s BlockCache.
> This patch will help users to clear the block cache for a given table by 
> either using shell or API.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217820#comment-16217820
 ] 

stack commented on HBASE-19057:
---

That looks good.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217819#comment-16217819
 ] 

stack commented on HBASE-19002:
---

Examples written by another that make use of the APIs (and presumptions) would 
reveal holes as [~Apache9] suggests. If not [~ted_yu] I can ask around...

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19057) Fix other code review comments about FilterList Improvement

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217818#comment-16217818
 ] 

Hadoop QA commented on HBASE-19057:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 19m 
32s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  1m 
46s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
57s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
57s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
58s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
38s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
34s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
23s{color} | {color:green} HBASE-18410 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
52s{color} | {color:green} HBASE-18410 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m  
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
27s{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}  3m 
54s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
38m 36s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
28s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}127m 
24s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
33s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}218m 30s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19057 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12893771/HBASE-19057-HBASE-18410.v5.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux af118bd980e6 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26 
18:04:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | HBASE-18410 / 

[jira] [Updated] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19057:
--
Status: Patch Available  (was: In Progress)

Assigned myself so I could resubmit. Assigning back.

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reassigned HBASE-19057:
-

Assignee: Zheng Hu  (was: stack)

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19057:
--
Status: In Progress  (was: Patch Available)

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-19057) Fix other code review comments about FilterList Improvement

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack reassigned HBASE-19057:
-

Assignee: stack  (was: Zheng Hu)

> Fix other code review comments about FilterList Improvement
> ---
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Zheng Hu
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch, 
> HBASE-19057-HBASE-18410.v2.patch, HBASE-19057-HBASE-18410.v3.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v4.patch, 
> HBASE-19057-HBASE-18410.v4.patch, HBASE-19057-HBASE-18410.v5.patch, 
> HBASE-19057-HBASE-18410.v5.patch, HBASE-19057-HBASE-18410.v5.patch
>
>
> Open this issue to  fix conflict , run HadoopQA  and gather other feedback. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18995) Move methods that are for internal usage from CellUtil to Private util class

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-18995:
--
Fix Version/s: (was: 2.0.0-beta-1)
   2.0.0-alpha-4

> Move methods that are for internal usage from CellUtil to Private util class
> 
>
> Key: HBASE-18995
> URL: https://issues.apache.org/jira/browse/HBASE-18995
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18995-branch-2.patch
>
>
> This was brought up long time back. We need to move some of the public APIs 
> from CellUtil to internal private Util class because they are used in some 
> internal flow and does not make sense to have it in a @public exposed Util 
> class. 
> The topic again came in HBASE-18945 RB comments also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19074) Miscellaneous Observer cleanups

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217770#comment-16217770
 ] 

Hudson commented on HBASE-19074:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3943 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3943/])
HBASE-19074 Miscellaneous Observer cleanups Breaks MemStoreSize into (stack: 
rev cb506fd4019556ec5535310b38e99b1ebfdf80bb)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/AbstractTestWALReplay.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellChunkImmutableSegment.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellArrayImmutableSegment.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MutableSegment.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/DefaultMemStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/AbstractMemStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactingMemStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Segment.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SegmentFactory.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactionPipeline.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MiniBatchOperationInProgress.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactingToCellFlatMapMemStore.java
* (add) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerAccounting.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompositeImmutableSegment.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/WALObserver.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestDefaultMemStore.java


> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch, 
> HBASE-19074.master.002.patch, HBASE-19074.master.003.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few 
> violations such as Store returning a MemStoreSize instance (which would let 
> coprocessors inc/dec MemStore size which would mess us up). This issue is 
> about cleaning these remainders up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19070) temporarily make the mvnsite nightly test non-voting.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217771#comment-16217771
 ] 

Hudson commented on HBASE-19070:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3943 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3943/])
HBASE-19070 temporarily make the mvnsite nightly test non-voting. (busbey: rev 
cda2949b816fceb4d63d2d9ca445bc75912227e2)
* (edit) dev-support/Jenkinsfile


> temporarily make the mvnsite nightly test non-voting.
> -
>
> Key: HBASE-19070
> URL: https://issues.apache.org/jira/browse/HBASE-19070
> Project: HBase
>  Issue Type: Sub-task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19070.0.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19070) temporarily make the mvnsite nightly test non-voting.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217764#comment-16217764
 ] 

Hudson commented on HBASE-19070:


SUCCESS: Integrated in Jenkins build HBase-1.4 #971 (See 
[https://builds.apache.org/job/HBase-1.4/971/])
HBASE-19070 temporarily make the mvnsite nightly test non-voting. (busbey: rev 
c3e03e528ac362d98047dfb34e8bac528493f5e0)
* (edit) dev-support/Jenkinsfile


> temporarily make the mvnsite nightly test non-voting.
> -
>
> Key: HBASE-19070
> URL: https://issues.apache.org/jira/browse/HBASE-19070
> Project: HBase
>  Issue Type: Sub-task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19070.0.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19070) temporarily make the mvnsite nightly test non-voting.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217754#comment-16217754
 ] 

Hudson commented on HBASE-19070:


SUCCESS: Integrated in Jenkins build HBase-1.5 #113 (See 
[https://builds.apache.org/job/HBase-1.5/113/])
HBASE-19070 temporarily make the mvnsite nightly test non-voting. (busbey: rev 
490444c70d833261776a1a1ce38587e2bdba6aa1)
* (edit) dev-support/Jenkinsfile


> temporarily make the mvnsite nightly test non-voting.
> -
>
> Key: HBASE-19070
> URL: https://issues.apache.org/jira/browse/HBASE-19070
> Project: HBase
>  Issue Type: Sub-task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19070.0.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19047) CP exposed Scanner types should not extend Shipper

[Ted Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217753#comment-16217753
 ] 

Ted Yu commented on HBASE-19047:


+1

> CP exposed Scanner types should not extend Shipper
> --
>
> Key: HBASE-19047
> URL: https://issues.apache.org/jira/browse/HBASE-19047
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19047.patch
>
>
> Shipper is a IA.Private interface and very much internal.. 
> Right now CP exposed RegionScanner is extending this and so exposing the 
> shipped() method. This by mistake is called, can harm the correctness of the 
> cells in the Results.
> preScannerOpen() allowing to return a new Scanner is also problematic now.  
> This can allow users to create a Region scanner from Region and then wrap it 
> and return back (Well same can be done by postScannerOpen also), it can so 
> happen that the wrapper is not implementing the shipped() properly.  In any 
> way exposing the shipped () is problematic.
> Solution Steps
> 1. Remove preScannerOpen() , the use case I can think of is wrapping the 
> original scanner. The original scanner can be created by Region.getScanner 
> way only..  May be no need to remove this hook.  Just remove the ability for 
> it to return a RegionScanner instance.  Call this with the Scan object and 
> the CP can change the Scan object if they want.
> 2. Let RegionScanner not extending Shipper but only RegionScannerImpl 
> implements this
> 3. We have ref to the RegionScanner created by core and let that be used by 
> RegionScannerShippedCallBack when the post hook doing a wrap.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18995) Move methods that are for internal usage from CellUtil to Private util class

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217732#comment-16217732
 ] 

Hadoop QA commented on HBASE-18995:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m 
21s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 29 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  1m 
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
51s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
59s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
29s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  1m 
25s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  8m 
 6s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red}  2m  
6s{color} | {color:red} hbase-server in branch-2 has 1 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
46s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  1m 
16s{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 
 5s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
38m 19s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  6m  
8s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red}  0m 
16s{color} | {color:red} hbase-common generated 4 new + 0 unchanged - 0 fixed = 
4 total (was 0) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m  
9s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
31s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
25s{color} | {color:green} hbase-prefix-tree in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 19m 41s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 16m 32s{color} 
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 15m 49s{color} 
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
52s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}153m 54s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | 

[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g

[Tamas Penzes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Penzes updated HBASE-13346:
-
Status: Patch Available  (was: Open)

> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
>  Issue Type: Bug
>  Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch, 
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch, 
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch, 
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch, 
> HBASE-13346.master.007.patch, HBASE-13346.master.008.patch, 
> HBASE-13346.master.009.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference 
> mixed up all over the place, I recommend cleaning this up once and for all. 
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or 
> parameter name.
> This includes deprecating and renaming filters too, for example 
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}} 
> as it does _not_ just return the key, but the entire cell. It should be 
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if 
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs 
> {{Column}} in our naming. The latter two are the only ones going forward with 
> the public API, and are used synonymous. We should carefully check which is 
> better suited (is it really a specific cell, or the newest cell, aka the 
> newest column value) and settle on a naming schema.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g

[Tamas Penzes (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Penzes updated HBASE-13346:
-
Status: Open  (was: Patch Available)

> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
>  Issue Type: Bug
>  Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch, 
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch, 
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch, 
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch, 
> HBASE-13346.master.007.patch, HBASE-13346.master.008.patch, 
> HBASE-13346.master.009.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference 
> mixed up all over the place, I recommend cleaning this up once and for all. 
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or 
> parameter name.
> This includes deprecating and renaming filters too, for example 
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}} 
> as it does _not_ just return the key, but the entire cell. It should be 
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if 
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs 
> {{Column}} in our naming. The latter two are the only ones going forward with 
> the public API, and are used synonymous. We should carefully check which is 
> better suited (is it really a specific cell, or the newest cell, aka the 
> newest column value) and settle on a naming schema.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-19002:
--
Priority: Minor  (was: Major)

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19073) Cleanup CoordinatedStateManager

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217649#comment-16217649
 ] 

Appy commented on HBASE-19073:
--

So running all master tests passed. I had fork count=5 to make sure that it's 
not failing because of some weird concurrency issue in testing.

{noformat}
$ mvn test -Dtest=org.apache.hadoop.hbase.master.Test* 
-Dsurefire.firstPartForkCount=5 -pl hbase-server
...

Tests run: 104, Failures: 0, Errors: 0, Skipped: 24


--- maven-surefire-plugin:2.20.1:test (secondPartTestsExecution) @ hbase-server 
---
Tests are skipped.

BUILD SUCCESS

Total time: 04:37 min
Finished at: 2017-10-24T13:20:08-07:00
Final Memory: 79M/836M

{noformat}

I have no idea why its failing because the test being changed in this patch, 
testDelayedDeleteOnFailure, runs after the test that's failing, 
testThreeRSAbort. So that can't be it.

Doing another QA run.


> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19073.master.001.patch, 
> HBASE-19073.master.002.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to 
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-19073) Cleanup CoordinatedStateManager

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217615#comment-16217615
 ] 

Appy edited comment on HBASE-19073 at 10/24/17 8:21 PM:


Maybe it's just that timeout of 30 sec is less for the test?
Running all master tests locally.
{{mvn test -Dtest=org.apache.hadoop.hbase.master.Test* 
-Dsurefire.firstPartForkCount=5 -pl hbase-server}}

Edit: Sorry, timeout is 300 sec not 30 sec. That should be enough.


was (Author: appy):
Maybe it's just that timeout of 30 sec is less for the test?
Running all master tests locally.
{{mvn test -Dtest=org.apache.hadoop.hbase.master.Test* 
-Dsurefire.firstPartForkCount=5 -pl hbase-server}}

> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19073.master.001.patch, 
> HBASE-19073.master.002.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to 
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19047) CP exposed Scanner types should not extend Shipper

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217626#comment-16217626
 ] 

stack commented on HBASE-19047:
---

Whats going on in Export? Calling Scanner CP hooks? Why is it allowed to do 
that (Not your change)

+1



> CP exposed Scanner types should not extend Shipper
> --
>
> Key: HBASE-19047
> URL: https://issues.apache.org/jira/browse/HBASE-19047
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19047.patch
>
>
> Shipper is a IA.Private interface and very much internal.. 
> Right now CP exposed RegionScanner is extending this and so exposing the 
> shipped() method. This by mistake is called, can harm the correctness of the 
> cells in the Results.
> preScannerOpen() allowing to return a new Scanner is also problematic now.  
> This can allow users to create a Region scanner from Region and then wrap it 
> and return back (Well same can be done by postScannerOpen also), it can so 
> happen that the wrapper is not implementing the shipped() properly.  In any 
> way exposing the shipped () is problematic.
> Solution Steps
> 1. Remove preScannerOpen() , the use case I can think of is wrapping the 
> original scanner. The original scanner can be created by Region.getScanner 
> way only..  May be no need to remove this hook.  Just remove the ability for 
> it to return a RegionScanner instance.  Call this with the Scan object and 
> the CP can change the Scan object if they want.
> 2. Let RegionScanner not extending Shipper but only RegionScannerImpl 
> implements this
> 3. We have ref to the RegionScanner created by core and let that be used by 
> RegionScannerShippedCallBack when the post hook doing a wrap.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19073) Cleanup CoordinatedStateManager

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217615#comment-16217615
 ] 

Appy commented on HBASE-19073:
--

Maybe it's just that timeout of 30 sec is less for the test?
Running all master tests locally.
{{mvn test -Dtest=org.apache.hadoop.hbase.master.Test* 
-Dsurefire.firstPartForkCount=5 -pl hbase-server}}

> Cleanup CoordinatedStateManager
> ---
>
> Key: HBASE-19073
> URL: https://issues.apache.org/jira/browse/HBASE-19073
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19073.master.001.patch, 
> HBASE-19073.master.002.patch
>
>
> - Remove the configuration hbase.coordinated.state.manager.class
> - Keep following interface since they nicely separate ZK based
> implementation: SplitLogWorkerCoordination, SplitLogManagerCoordination,
> ProcedureCoordinatorRpcs, ProcedureMemberRpcs
> - Replace CSM (interface) + BCSM (unnecessary middle hierarchy) with single
> CSM interface.
> - Don't pass whole CSM object around (with server in it which gives acess to 
> pretty much everything), only pass the relevant dependencies.
> Discussion thread on dev@ mailing list.
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201710.mbox/%3CCAAjhxrqjOg90Fdi73kZZe_Gxtrqq8ff%2B%3DAj_epptO_XO812Abg%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19074) Miscellaneous Observer cleanups

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19074:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks [~mdrob]

Pushed to master and branch-2. Resolving.

> Miscellaneous Observer cleanups
> ---
>
> Key: HBASE-19074
> URL: https://issues.apache.org/jira/browse/HBASE-19074
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19074.master.001.patch, 
> HBASE-19074.master.002.patch, HBASE-19074.master.003.patch
>
>
> Going through Observers after fixing up MasterObserver, i see a few 
> violations such as Store returning a MemStoreSize instance (which would let 
> coprocessors inc/dec MemStore size which would mess us up). This issue is 
> about cleaning these remainders up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18995) Move methods that are for internal usage from CellUtil to Private util class

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16217605#comment-16217605
 ] 

stack commented on HBASE-18995:
---

License text is mangled in a few files.

Fix this text on CellUtil:

46   * Utility methods helpful slinging {@link Cell} instances. Some 
methods below are for internal use
47   * only and are marked InterfaceAudience.Private at the method level.

Or I suppose, it still holds. The Private methods have been Deprecated.

Deprecation in CellUtil is good.

I don't like the name InternalCellUtil but it is explicit as to its use.

Change this? 47 
@InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC) to Private I'd 
say... CPs messing w/ Cells other than Reading is not to be encouraged I'd say 
(They can construct over in CellUtil...)

Skimmed... looking good.



> Move methods that are for internal usage from CellUtil to Private util class
> 
>
> Key: HBASE-18995
> URL: https://issues.apache.org/jira/browse/HBASE-18995
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18995-branch-2.patch
>
>
> This was brought up long time back. We need to move some of the public APIs 
> from CellUtil to internal private Util class because they are used in some 
> internal flow and does not make sense to have it in a @public exposed Util 
> class. 
> The topic again came in HBASE-18945 RB comments also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)