[jira] [Reopened] (HBASE-14498) Master stuck in infinite loop when all Zookeeper servers are unreachable

[stack (JIRA)]

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

stack reopened HBASE-14498:
---

Reopening to apply to earlier branches.

> Master stuck in infinite loop when all Zookeeper servers are unreachable
> 
>
> Key: HBASE-14498
> URL: https://issues.apache.org/jira/browse/HBASE-14498
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Reporter: Y. SREENIVASULU REDDY
>Assignee: Pankaj Kumar
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14498.master.001.patch, 
> HBASE-14498.master.002.patch, HBASE-14498.patch, HBASE-14498-V2.patch, 
> HBASE-14498-V3.patch, HBASE-14498-V4.patch, HBASE-14498-V5.patch, 
> HBASE-14498-V6.patch, HBASE-14498-V6.patch
>
>
> We met a weird scenario in our production environment.
> In a HA cluster,
> > Active Master (HM1) is not able to connect to any Zookeeper server (due to 
> > N/w breakdown on master machine network with Zookeeper servers).
> {code}
> 2015-09-26 15:24:47,508 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 33463ms for sessionid 0x104576b8dda0002, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:24:47,877 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:48,236 INFO [main-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:49,879 WARN 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:49,879 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-IP1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:24:50,238 WARN [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:50,238 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-Host1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:25:17,470 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 30023ms for sessionid 0x2045762cc710006, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:25:17,571 WARN [master/HM1-Host/HM1-IP:16000] 
> zookeeper.RecoverableZooKeeper: Possibly transient ZooKeeper, 
> quorum=ZK-Host:2181,ZK-Host1:2181,ZK-Host2:2181, 
> exception=org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /hbase/master
> 2015-09-26 15:25:17,872 INFO [main-SendThread(ZK-Host:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host 2181
> 2015-09-26 15:25:19,874 WARN [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host
> 2015-09-26 15:25:19,874 INFO [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server ZK-Host/ZK-IP:2181. 
> Will not attempt to authenticate using SASL (unknown error)
> {code}
> > Since HM1 was not able to connect to any ZK, so session timeout didnt 
> > happen at Zookeeper server side and HM1 didnt abort.
> > On Zookeeper session timeout standby master (HM2) registered himself as an 
> > active master. 
> > HM2 is keep on waiting for region server to report him as part of active 
> > master intialization.
> {noformat} 
> 2015-09-26 15:24:44,928 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 0 ms, 
> expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, interval 
> of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> ---
> ---
> 2015-09-26 15:32:50,841 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 483913 
> ms, expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, 
> interval of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> {noformat}
> > At other end, region servers are reporting to HM1 on 3 sec interval. Here 
> > region server retrieve master location from zookeeper only when they 
> > couldn't connect to Master (ServiceException).
> Region Server will not report HM2 as per current design until unless HM1 
> abort,so HM2 will exit(InitializationMonitor) and again wait for region 
> servers in 

[jira] [Commented] (HBASE-14498) Master stuck in infinite loop when all Zookeeper servers are unreachable

[Pankaj Kumar (JIRA)]

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

Pankaj Kumar commented on HBASE-14498:
--

Thanks Stack...!! 

Shall we fix this issue in branch-1/1.4/1.3?

> Master stuck in infinite loop when all Zookeeper servers are unreachable
> 
>
> Key: HBASE-14498
> URL: https://issues.apache.org/jira/browse/HBASE-14498
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Reporter: Y. SREENIVASULU REDDY
>Assignee: Pankaj Kumar
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14498.master.001.patch, 
> HBASE-14498.master.002.patch, HBASE-14498.patch, HBASE-14498-V2.patch, 
> HBASE-14498-V3.patch, HBASE-14498-V4.patch, HBASE-14498-V5.patch, 
> HBASE-14498-V6.patch, HBASE-14498-V6.patch
>
>
> We met a weird scenario in our production environment.
> In a HA cluster,
> > Active Master (HM1) is not able to connect to any Zookeeper server (due to 
> > N/w breakdown on master machine network with Zookeeper servers).
> {code}
> 2015-09-26 15:24:47,508 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 33463ms for sessionid 0x104576b8dda0002, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:24:47,877 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:48,236 INFO [main-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:49,879 WARN 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:49,879 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-IP1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:24:50,238 WARN [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:50,238 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-Host1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:25:17,470 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 30023ms for sessionid 0x2045762cc710006, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:25:17,571 WARN [master/HM1-Host/HM1-IP:16000] 
> zookeeper.RecoverableZooKeeper: Possibly transient ZooKeeper, 
> quorum=ZK-Host:2181,ZK-Host1:2181,ZK-Host2:2181, 
> exception=org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /hbase/master
> 2015-09-26 15:25:17,872 INFO [main-SendThread(ZK-Host:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host 2181
> 2015-09-26 15:25:19,874 WARN [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host
> 2015-09-26 15:25:19,874 INFO [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server ZK-Host/ZK-IP:2181. 
> Will not attempt to authenticate using SASL (unknown error)
> {code}
> > Since HM1 was not able to connect to any ZK, so session timeout didnt 
> > happen at Zookeeper server side and HM1 didnt abort.
> > On Zookeeper session timeout standby master (HM2) registered himself as an 
> > active master. 
> > HM2 is keep on waiting for region server to report him as part of active 
> > master intialization.
> {noformat} 
> 2015-09-26 15:24:44,928 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 0 ms, 
> expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, interval 
> of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> ---
> ---
> 2015-09-26 15:32:50,841 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 483913 
> ms, expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, 
> interval of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> {noformat}
> > At other end, region servers are reporting to HM1 on 3 sec interval. Here 
> > region server retrieve master location from zookeeper only when they 
> > couldn't connect to Master (ServiceException).
> Region Server will not report HM2 as per current design until unless HM1 
> abort,so 

[jira] [Commented] (HBASE-18626) Handle the incompatible change about the replication TableCFs' config

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang commented on HBASE-18626:


HBASE-16653 backport this incompatible change to branch-1, so I thought we need 
handle this when rolling update from 1.3 to 1.4, too. FYI: [~apurtell]

> Handle the incompatible change about the replication TableCFs' config
> -
>
> Key: HBASE-18626
> URL: https://issues.apache.org/jira/browse/HBASE-18626
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Priority: Blocker
>
> About compatibility, there is one incompatible change about the replication 
> TableCFs' config. The old config is a string and it concatenate the list of 
> tables and column families in format "table1:cf1,cf2;table2:cfA,cfB" in 
> zookeeper for table-cf to replication peer mapping. When parse the config, it 
> use ":" to split the string. If table name includes namespace, it will be 
> wrong (See HBASE-11386). It is a problem since we support namespace (0.98). 
> So HBASE-11393 (and HBASE-16653) changed it to a PB object. When rolling 
> update cluster, you need rolling master first. And the master will try to 
> translate the string config to a PB object. But there are two problems.
> 1. Permission problem. The replication client can write the zookeeper 
> directly. So the znode may have different owner. And master may don't have 
> the write permission for the znode. It maybe failed to translate old 
> table-cfs string to new PB Object. See HBASE-16938
> 2. We usually keep compatibility between old client and new server. But the 
> old replication client may write a string config to znode directly. Then the 
> new server can't parse them.



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

[jira] [Comment Edited] (HBASE-18626) Handle the incompatible change about the replication TableCFs' config

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang edited comment on HBASE-18626 at 8/18/17 5:35 AM:
-

HBASE-16653 backport this incompatible change to branch-1, so I thought we need 
handle this when rolling update to 1.4, too. FYI: [~apurtell]


was (Author: zghaobac):
HBASE-16653 backport this incompatible change to branch-1, so I thought we need 
handle this when rolling update from 1.3 to 1.4, too. FYI: [~apurtell]

> Handle the incompatible change about the replication TableCFs' config
> -
>
> Key: HBASE-18626
> URL: https://issues.apache.org/jira/browse/HBASE-18626
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Priority: Blocker
>
> About compatibility, there is one incompatible change about the replication 
> TableCFs' config. The old config is a string and it concatenate the list of 
> tables and column families in format "table1:cf1,cf2;table2:cfA,cfB" in 
> zookeeper for table-cf to replication peer mapping. When parse the config, it 
> use ":" to split the string. If table name includes namespace, it will be 
> wrong (See HBASE-11386). It is a problem since we support namespace (0.98). 
> So HBASE-11393 (and HBASE-16653) changed it to a PB object. When rolling 
> update cluster, you need rolling master first. And the master will try to 
> translate the string config to a PB object. But there are two problems.
> 1. Permission problem. The replication client can write the zookeeper 
> directly. So the znode may have different owner. And master may don't have 
> the write permission for the znode. It maybe failed to translate old 
> table-cfs string to new PB Object. See HBASE-16938
> 2. We usually keep compatibility between old client and new server. But the 
> old replication client may write a string config to znode directly. Then the 
> new server can't parse them.



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

[jira] [Commented] (HBASE-18518) Remove jersey1* dependencies from project and jersey1* jars from lib dir

[stack (JIRA)]

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

stack commented on HBASE-18518:
---

Hmm. So this makes the tests pass but when I run the REST server apart, I get 
the below:

{code}
Exception in thread "main" java.lang.NoSuchMethodError: 
javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
  at 
org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.java:331)
  at org.glassfish.jersey.servlet.WebComponent.(WebComponent.java:392)
  at 
org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177)
  at 
org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:369)
  at javax.servlet.GenericServlet.init(GenericServlet.java:244)
  at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:640)
  at org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:419)
  at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:875)
  at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:348)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
  at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:261)
  at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
  at org.eclipse.jetty.server.Server.start(Server.java:405)
  at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
  at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
  at org.eclipse.jetty.server.Server.doStart(Server.java:372)
  at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
  at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:354)
{code}

This was because it was finding ApplicationHandler in the jersey1 coming in 
from hadoop. I seemed to have it 'fixed' in my patch but merging it and yours 
doesn't seem to get this... Let me look at it.

I'll leave the patch in because it at least makes the REST tests pass again.

> Remove jersey1* dependencies from project and jersey1* jars from lib dir
> 
>
> Key: HBASE-18518
> URL: https://issues.apache.org/jira/browse/HBASE-18518
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, pom, REST
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Samir Ahmic
>Assignee: Samir Ahmic
>  Labels: cleanup
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18518-master-01.patch, HBASE-18518-master-02.patch
>
>
> Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and 
> it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. 
> With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced 
> jersey2 to project,  and we also  have bunch of transitive dependencies 
> (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 
> and jersey2 under same classpath can case runtime issues as it was case with 
> rest.
> This task will have following steps
> * Clean code and replace jersey1 constructs with jersey2 versions(there 
> should not be much of this)
> * Add exclusions for transitive jersey1 dependencies in pom.xml
> * Add exclusions  in hadoop-two-compat.xml to prevent jersey1 jars in lib dir



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

[jira] [Created] (HBASE-18626) Handle the incompatible change about the replication TableCFs' config

[Guanghao Zhang (JIRA)]

Guanghao Zhang created HBASE-18626:
--

 Summary: Handle the incompatible change about the replication 
TableCFs' config
 Key: HBASE-18626
 URL: https://issues.apache.org/jira/browse/HBASE-18626
 Project: HBase
  Issue Type: Bug
Reporter: Guanghao Zhang
Priority: Blocker


About compatibility, there is one incompatible change about the replication 
TableCFs' config. The old config is a string and it concatenate the list of 
tables and column families in format "table1:cf1,cf2;table2:cfA,cfB" in 
zookeeper for table-cf to replication peer mapping. When parse the config, it 
use ":" to split the string. If table name includes namespace, it will be wrong 
(See HBASE-11386). It is a problem since we support namespace (0.98). So 
HBASE-11393 (and HBASE-16653) changed it to a PB object. When rolling update 
cluster, you need rolling master first. And the master will try to translate 
the string config to a PB object. But there are two problems.
1. Permission problem. The replication client can write the zookeeper directly. 
So the znode may have different owner. And master may don't have the write 
permission for the znode. It maybe failed to translate old table-cfs string to 
new PB Object. See HBASE-16938
2. We usually keep compatibility between old client and new server. But the old 
replication client may write a string config to znode directly. Then the new 
server can't parse them.



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

[jira] [Updated] (HBASE-18518) Remove jersey1* dependencies from project and jersey1* jars from lib dir

[stack (JIRA)]

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

stack updated HBASE-18518:
--
Fix Version/s: (was: 3.0.0)
   2.0.0-alpha-3

> Remove jersey1* dependencies from project and jersey1* jars from lib dir
> 
>
> Key: HBASE-18518
> URL: https://issues.apache.org/jira/browse/HBASE-18518
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, pom, REST
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Samir Ahmic
>Assignee: Samir Ahmic
>  Labels: cleanup
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18518-master-01.patch, HBASE-18518-master-02.patch
>
>
> Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and 
> it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. 
> With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced 
> jersey2 to project,  and we also  have bunch of transitive dependencies 
> (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 
> and jersey2 under same classpath can case runtime issues as it was case with 
> rest.
> This task will have following steps
> * Clean code and replace jersey1 constructs with jersey2 versions(there 
> should not be much of this)
> * Add exclusions for transitive jersey1 dependencies in pom.xml
> * Add exclusions  in hadoop-two-compat.xml to prevent jersey1 jars in lib dir



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

[jira] [Updated] (HBASE-18518) Remove jersey1* dependencies from project and jersey1* jars from lib dir

[stack (JIRA)]

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

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

Tried it locally. Its lovely. Thank you [~asamir]. Pushed to master and 
branch-2.

> Remove jersey1* dependencies from project and jersey1* jars from lib dir
> 
>
> Key: HBASE-18518
> URL: https://issues.apache.org/jira/browse/HBASE-18518
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, pom, REST
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Samir Ahmic
>Assignee: Samir Ahmic
>  Labels: cleanup
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18518-master-01.patch, HBASE-18518-master-02.patch
>
>
> Recently i have opened https://issues.apache.org/jira/browse/HBASE-18506 and 
> it is clear that is caused by mixing jersey1 and jersey2 jars in classpath. 
> With https://issues.apache.org/jira/browse/HBASE-12894 we have introduced 
> jersey2 to project,  and we also  have bunch of transitive dependencies 
> (mainly from hadoop) on jersey1 which is not happiest situation since jersey1 
> and jersey2 under same classpath can case runtime issues as it was case with 
> rest.
> This task will have following steps
> * Clean code and replace jersey1 constructs with jersey2 versions(there 
> should not be much of this)
> * Add exclusions for transitive jersey1 dependencies in pom.xml
> * Add exclusions  in hadoop-two-compat.xml to prevent jersey1 jars in lib dir



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

[jira] [Commented] (HBASE-18615) hbase-rest tests fail in hbase-2.0.0-alpha2

[stack (JIRA)]

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

stack commented on HBASE-18615:
---

Argh! I've been banging my head against this this evening and you'd figured 
it out a while back [~asamir]! Let me look... looks like you were doing a 
better job too.. I have the stuff hacking out jersey1 and then some mess to 
override its finding default jersey1 for ResourceDelegate...  Let me look.

> hbase-rest tests fail in hbase-2.0.0-alpha2
> ---
>
> Key: HBASE-18615
> URL: https://issues.apache.org/jira/browse/HBASE-18615
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: stack
>
> Pointed out by Andrew on VOTE mail



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

[jira] [Updated] (HBASE-18099) FlushSnapshotSubprocedure should wait for concurrent Region#flush() to finish

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-18099:

Component/s: snapshots

> FlushSnapshotSubprocedure should wait for concurrent Region#flush() to finish
> -
>
> Key: HBASE-18099
> URL: https://issues.apache.org/jira/browse/HBASE-18099
> Project: HBase
>  Issue Type: Bug
>  Components: snapshots
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 18099.v1.txt, 18099.v2.txt, 18099.v3.txt, 18099.v4.txt
>
>
> In the following thread:
> http://search-hadoop.com/m/HBase/YGbbMXkeHlI9zo
> Jacob described the scenario where data from certain region were missing in 
> the snapshot.
> Here was related region server log:
> https://pastebin.com/1ECXjhRp
> He pointed out that concurrent flush from MemStoreFlusher.1 thread was not 
> initiated from the thread pool for snapshot.
> In RegionSnapshotTask#call() method there is this:
> {code}
>   region.flush(true);
> {code}
> The return value is not checked.
> In HRegion#flushcache(), Result.CANNOT_FLUSH may be returned due to:
> {code}
>   String msg = "Not flushing since "
>   + (writestate.flushing ? "already flushing"
>   : "writes not enabled");
> {code}
> This implies that FlushSnapshotSubprocedure may incorrectly skip waiting for 
> the concurrent flush to complete.



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

[jira] [Updated] (HBASE-18358) Backport HBASE-18099 'FlushSnapshotSubprocedure should wait for concurrent Region#flush() to finish' to branch-1.3

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-18358:

Component/s: snapshots

> Backport HBASE-18099 'FlushSnapshotSubprocedure should wait for concurrent 
> Region#flush() to finish' to branch-1.3
> --
>
> Key: HBASE-18358
> URL: https://issues.apache.org/jira/browse/HBASE-18358
> Project: HBase
>  Issue Type: Bug
>  Components: snapshots
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-2
>
> Attachments: 18358.branch-1.3.patch, 18358.v2.txt, 18358.v3.txt
>
>
> HBASE-18099 was only integrated to branch-1 and above in consideration of 
> backward compatibility.
> This issue is to backport the fix to branch-1.3 and branch-1.2.
> Quoting Gary's suggestion from the tail of HBASE-18099 :
> {quote}
> Sure, don't add the method to Region, just to HRegion, check for an instance 
> of HRegion in FlushSnapshotSubprocedure and cast the instance before calling 
> the method.
> {quote}



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

[jira] [Commented] (HBASE-18347) Implement a BufferedMutator for async client

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18347:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
41s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
50s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
51s{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} hadoopcheck {color} | {color:green} 
35m 47s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
41s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}118m 24s{color} 
| {color:red} hbase-server in the patch failed. {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}180m 19s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | 
org.apache.hadoop.hbase.client.TestAsyncClusterAdminApi2 |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18347 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12882485/HBASE-18347-v1.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 17ab4bb388a9 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31 
14:13:22 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 / 75a6b36 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8141/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8141/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output | 

[jira] [Commented] (HBASE-18615) hbase-rest tests fail in hbase-2.0.0-alpha2

[Samir Ahmic (JIRA)]

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

Samir Ahmic commented on HBASE-18615:
-

[~stack] please take look at HBASE-18518 i was replacing jersey1 with jersey2 
in hbase-rest on master maybe we can do same on hbase-2.0.0-alpha2.

> hbase-rest tests fail in hbase-2.0.0-alpha2
> ---
>
> Key: HBASE-18615
> URL: https://issues.apache.org/jira/browse/HBASE-18615
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: stack
>
> Pointed out by Andrew on VOTE mail



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

[jira] [Commented] (HBASE-18552) Backport the server side change in HBASE-18489 to branch-1

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18552:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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}  1m 
53s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
33s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
33s{color} | {color:green} branch-1 passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
56s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
17s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
55s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
27s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
32s{color} | {color:green} branch-1 passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  0m 
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
34s{color} | {color:green} the patch passed with JDK v1.7.0_131 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
15m 25s{color} | {color:green} The patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m  
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
26s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
33s{color} | {color:green} the patch passed with JDK v1.7.0_131 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 93m 29s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
18s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}123m 18s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestClientScannerRPCTimeout |
|   | hadoop.hbase.regionserver.TestRSKilledWhenInitializing |
|   | hadoop.hbase.coprocessor.TestRowProcessorEndpoint |
|   | hadoop.hbase.master.TestMasterFailover |
| Timed out junit tests | 
org.apache.hadoop.hbase.client.TestTableSnapshotScanner |
|   | org.apache.hadoop.hbase.mapred.TestTableSnapshotInputFormat |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18552 |
| JIRA Patch URL | 

[jira] [Comment Edited] (HBASE-14785) Hamburger menu for mobile site

[Mike Drob (JIRA)]

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

Mike Drob edited comment on HBASE-14785 at 8/18/17 4:27 AM:


Sometimes I see a directory created in top level called "\{project.basedir}" - 
is the repo url already assumed to be relative?

Also, I could be generating that from an old branch if that has already been 
fixed somewhere...

[~misty] - thoughts?


was (Author: mdrob):
Sometimes I see a directory created in top level called "{project.basedir}" - 
is the repo url already assumed to be relative?

Also, I could be generating that from an old branch if that has already been 
fixed somewhere...

[~misty] - thoughts?

> Hamburger menu for mobile site
> --
>
> Key: HBASE-14785
> URL: https://issues.apache.org/jira/browse/HBASE-14785
> Project: HBase
>  Issue Type: Sub-task
>  Components: website
>Affects Versions: 2.0.0
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: 
> 0001-HBASE-14774-Addendum-Exclude-src-main-site-resources.patch, 
> HBASE-14774-addendum2_tweak_css.patch, HBASE-14785-addendum.patch, 
> HBASE-14785-addendum-v1.patch, HBASE-14785.patch, HBASE-14785-v1.patch, 
> HBASE-14785-v2.patch, maven-fluido-skin-1.5-HBASE.jar
>
>
> Figure out how to do a hamburger menu on mobile.



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

[jira] [Commented] (HBASE-14785) Hamburger menu for mobile site

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-14785:
---

Sometimes I see a directory created in top level called "{project.basedir}" - 
is the repo url already assumed to be relative?

Also, I could be generating that from an old branch if that has already been 
fixed somewhere...

[~misty] - thoughts?

> Hamburger menu for mobile site
> --
>
> Key: HBASE-14785
> URL: https://issues.apache.org/jira/browse/HBASE-14785
> Project: HBase
>  Issue Type: Sub-task
>  Components: website
>Affects Versions: 2.0.0
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: 
> 0001-HBASE-14774-Addendum-Exclude-src-main-site-resources.patch, 
> HBASE-14774-addendum2_tweak_css.patch, HBASE-14785-addendum.patch, 
> HBASE-14785-addendum-v1.patch, HBASE-14785.patch, HBASE-14785-v1.patch, 
> HBASE-14785-v2.patch, maven-fluido-skin-1.5-HBASE.jar
>
>
> Figure out how to do a hamburger menu on mobile.



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

[jira] [Commented] (HBASE-18347) Implement a BufferedMutator for async client

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18347:


Should we add close check in AsyncBufferedMutatorImpl?

> Implement a BufferedMutator for async client
> 
>
> Key: HBASE-18347
> URL: https://issues.apache.org/jira/browse/HBASE-18347
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client
>Affects Versions: 3.0.0, 2.0.0-alpha-2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 3.0.0, 2.0.0-alpha-3
>
> Attachments: HBASE-18347.patch, HBASE-18347-v1.patch
>
>
> Need this if we want to replace the old implementation for sync client with 
> async client.



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

[jira] [Resolved] (HBASE-9417) SecureBulkLoadEndpoint should be folded in core

[Jerry He (JIRA)]

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

Jerry He resolved HBASE-9417.
-
   Resolution: Duplicate
Fix Version/s: (was: 2.0.0-alpha-3)

> SecureBulkLoadEndpoint should be folded in core
> ---
>
> Key: HBASE-9417
> URL: https://issues.apache.org/jira/browse/HBASE-9417
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, security
>Reporter: Enis Soztutar
>Priority: Critical
>
> In unsecure bulk loading, the client creates the files to be bulk loaded, and 
> asks the regionservers to do the operation. Bulk loading is performed by a 
> move, which would mean that the hbase user has to have WRITE permissions for 
> the bulk loaded files. If the client who has generated the files is different 
> than the hbase user, this creates an access denied exception if complete bulk 
> load is not run as the hbase user.
> I think even for unsecure mode, we should mimic what SecureBulkLoadEndpoint 
> does, where hbase creates a staging directory and the client hands off the 
> files to that directory with global perms. 
> Update: Now that HBASE-12052 enables running SecureBulkLoadEndpoint even in 
> unsecure deployments, we should consider bringing SecureBulkLoad into core 
> HBase (meaning implement the functionality in RegionServer instead of in the 
> coprocessor). 



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

[jira] [Updated] (HBASE-18625) Splitting of region with replica, doesn't update region list in serverHolding. A server crash leads to overlap.

[Igloo (JIRA)]

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

Igloo updated HBASE-18625:
--
Status: Patch Available  (was: Open)

> Splitting of region with replica, doesn't update region list in 
> serverHolding. A server crash leads to overlap.
> ---
>
> Key: HBASE-18625
> URL: https://issues.apache.org/jira/browse/HBASE-18625
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: Igloo
> Fix For: 1.2.7
>
>
> The situation can appear in following steps in release hbase1.2.6
> 1. create 'testtable', 'info', {REGION_REPLICATION=>2}
> 2. write somerecords into 'testtable'
> 3. split the table 'testtable'
> 4. after the spliting, the serverHoldings in RegionStates still holds the 
> regioninfo for the replica of parent region
> 5. restart the regionserver where the parent regions lo[link 
> title|http://example.com]cated
> 6. the offlined replica of parent region will be assigned in 
> ServerCrashProcedure. 
> hbase hbck 'testtable‘
> ERROR: Region { meta => null, hdfs => null, deployed => 
> qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe195b3cc4d08b2c078a687f6d
> ., replicaId => 1 } not in META, but deployed on 
> qabb-qa-hdp-hbase1,16020,1503022958093
>  18 ERROR: No regioninfo in Meta or HDFS. { meta => null, hdfs => null, 
> deployed => 
> qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe 
>195b3cc4d08b2c078a687f6d., replicaId => 1 }



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

[jira] [Comment Edited] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock

[Allan Yang (JIRA)]

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

Allan Yang edited comment on HBASE-18233 at 8/18/17 3:25 AM:
-

{quote}
Allan Yang Got notice from the user who was having trouble w/ increments being 
slow. They said this patch plus sort makes a big difference. Lets commit. I 
tried to but it has rotted. I'll have a look in next week or so unless you beat 
me too it. Good stuff.
{quote}
Good to know this patch works,  I will do the rebase if needed.


was (Author: allan163):
{quote}
Allan Yang Got notice from the user who was having trouble w/ increments being 
slow. They said this patch plus sort makes a big difference. Lets commit. I 
tried to but it has rotted. I'll have a look in next week or so unless you beat 
me too it. Good stuff.
{quote}
Good to know this patch works,  I will rebase the patch.

> We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
> -
>
> Key: HBASE-18233
> URL: https://issues.apache.org/jira/browse/HBASE-18233
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-18233-branch-1.2.patch, 
> HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch
>
>
> Please refer to the discuss in HBASE-18144
> https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701



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

[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock

[Allan Yang (JIRA)]

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

Allan Yang commented on HBASE-18233:


{quote}
Allan Yang Got notice from the user who was having trouble w/ increments being 
slow. They said this patch plus sort makes a big difference. Lets commit. I 
tried to but it has rotted. I'll have a look in next week or so unless you beat 
me too it. Good stuff.
{quote}
Good to know this patch works,  I will rebase the patch.

> We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
> -
>
> Key: HBASE-18233
> URL: https://issues.apache.org/jira/browse/HBASE-18233
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.7
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-18233-branch-1.2.patch, 
> HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch
>
>
> Please refer to the discuss in HBASE-18144
> https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701



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

[jira] [Resolved] (HBASE-18489) Expose scan cursor in RawScanResultConsumer

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-18489.
---
Resolution: Fixed

Pushed the addendum to master and branch-2.

> Expose scan cursor in RawScanResultConsumer
> ---
>
> Key: HBASE-18489
> URL: https://issues.apache.org/jira/browse/HBASE-18489
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18489-addendum.patch, HBASE-18489.patch, 
> HBASE-18489-v1.patch, HBASE-18489-v2.patch, HBASE-18489-v2.patch
>
>
> The first step of supporting scan cursor for async client.



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

[jira] [Updated] (HBASE-18489) Expose scan cursor in RawScanResultConsumer

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-18489:
--
Attachment: HBASE-18489-addendum.patch

> Expose scan cursor in RawScanResultConsumer
> ---
>
> Key: HBASE-18489
> URL: https://issues.apache.org/jira/browse/HBASE-18489
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18489-addendum.patch, HBASE-18489.patch, 
> HBASE-18489-v1.patch, HBASE-18489-v2.patch, HBASE-18489-v2.patch
>
>
> The first step of supporting scan cursor for async client.



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

[jira] [Updated] (HBASE-18624) Added support for clearing BlockCache

[Ajay Jadhav (JIRA)]

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

Ajay Jadhav updated HBASE-18624:

Issue Type: Sub-task  (was: Improvement)
Parent: HBASE-18477

> Added support for clearing BlockCache
> -
>
> 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: Ajay Jadhav
>Priority: Minor
> Fix For: 1.4.0
>
>
> 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] [Updated] (HBASE-18625) Splitting of region with replica, doesn't update region list in serverHolding. A server crash leads to overlap.

[Igloo (JIRA)]

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

Igloo updated HBASE-18625:
--
Description: 
The situation can appear in following steps in release hbase1.2.6

1. create 'testtable', 'info', {REGION_REPLICATION=>2}
2. write somerecords into 'testtable'
3. split the table 'testtable'
4. after the spliting, the serverHoldings in RegionStates still holds the 
regioninfo for the replica of parent region
5. restart the regionserver where the parent regions lo[link 
title|http://example.com]cated
6. the offlined replica of parent region will be assigned in 
ServerCrashProcedure. 

hbase hbck 'testtable‘

ERROR: Region { meta => null, hdfs => null, deployed => 
qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe195b3cc4d08b2c078a687f6d
., replicaId => 1 } not in META, but deployed on 
qabb-qa-hdp-hbase1,16020,1503022958093
 18 ERROR: No regioninfo in Meta or HDFS. { meta => null, hdfs => null, 
deployed => 
qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe   
 195b3cc4d08b2c078a687f6d., replicaId => 1 }





  was:
The situation can appear in following steps in release hbase1.2.6

1. create 'testtable', 'info', {REGION_REPLICATION=>2}
2. write somerecords into 'testtable'
3. split the table 'testtable'
4. after the spliting, the serverHoldings in RegionStates still holds the 
regioninfo for the replica of parent region
5. restart the regionserver where the parent regions lo[link 
title|http://example.com]cated
6. the offlined replica of parent region will be assigned in 
ServerCrashProcedure. 






> Splitting of region with replica, doesn't update region list in 
> serverHolding. A server crash leads to overlap.
> ---
>
> Key: HBASE-18625
> URL: https://issues.apache.org/jira/browse/HBASE-18625
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: Igloo
> Fix For: 1.2.7
>
>
> The situation can appear in following steps in release hbase1.2.6
> 1. create 'testtable', 'info', {REGION_REPLICATION=>2}
> 2. write somerecords into 'testtable'
> 3. split the table 'testtable'
> 4. after the spliting, the serverHoldings in RegionStates still holds the 
> regioninfo for the replica of parent region
> 5. restart the regionserver where the parent regions lo[link 
> title|http://example.com]cated
> 6. the offlined replica of parent region will be assigned in 
> ServerCrashProcedure. 
> hbase hbck 'testtable‘
> ERROR: Region { meta => null, hdfs => null, deployed => 
> qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe195b3cc4d08b2c078a687f6d
> ., replicaId => 1 } not in META, but deployed on 
> qabb-qa-hdp-hbase1,16020,1503022958093
>  18 ERROR: No regioninfo in Meta or HDFS. { meta => null, hdfs => null, 
> deployed => 
> qabb-qa-hdp-hbase1,16020,1503022958093;testtable,,1503022907686_0001.42d11cfe 
>195b3cc4d08b2c078a687f6d., replicaId => 1 }



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

[jira] [Updated] (HBASE-18625) Splitting of region with replica, doesn't update region list in serverHolding.

[He Fei (JIRA)]

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

He Fei updated HBASE-18625:
---
Description: 
The situation can appear in following steps in release hbase1.2.6

1. create 'testtable', 'info', {REGION_REPLICATION=>2}
2. write somerecords into 'testtable'
3. split the table 'testtable'
4. after the spliting, the serverHoldings in RegionStates still holds the 
regioninfo for the replica of parent region
5. restart the regionserver where the parent regions lo[link 
title|http://example.com]cated
6. the offlined replica of parent region will be assigned in 
ServerCrashProcedure. 





  was:
The situation can appear in following steps in release hbase1.2.6

1. create 'testtable', 'info', {REGION_REPLICATION=>2}
2. write somerecords into 'testtable'
3. split the table 'testtable'
4. after the spliting, the serverHoldings in RegionStates still holds the 
regioninfo for the replica of parent region
5. restart the regionserver where the parent regions lo[link 
title|http://example.com]cated
6. the offlined replica of parent region will be assigned in 
ServerCrashProcedure. 




> Splitting of region with replica, doesn't update region list in serverHolding.
> --
>
> Key: HBASE-18625
> URL: https://issues.apache.org/jira/browse/HBASE-18625
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: He Fei
> Fix For: 1.2.7
>
>
> The situation can appear in following steps in release hbase1.2.6
> 1. create 'testtable', 'info', {REGION_REPLICATION=>2}
> 2. write somerecords into 'testtable'
> 3. split the table 'testtable'
> 4. after the spliting, the serverHoldings in RegionStates still holds the 
> regioninfo for the replica of parent region
> 5. restart the regionserver where the parent regions lo[link 
> title|http://example.com]cated
> 6. the offlined replica of parent region will be assigned in 
> ServerCrashProcedure. 



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

[jira] [Updated] (HBASE-18625) Splitting of region with replica, doesn't update region list in serverHolding. A server crash leads to overlap.

[He Fei (JIRA)]

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

He Fei updated HBASE-18625:
---
Summary: Splitting of region with replica, doesn't update region list in 
serverHolding. A server crash leads to overlap.  (was: Splitting of region with 
replica, doesn't update region list in serverHolding.)

> Splitting of region with replica, doesn't update region list in 
> serverHolding. A server crash leads to overlap.
> ---
>
> Key: HBASE-18625
> URL: https://issues.apache.org/jira/browse/HBASE-18625
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.6
>Reporter: He Fei
> Fix For: 1.2.7
>
>
> The situation can appear in following steps in release hbase1.2.6
> 1. create 'testtable', 'info', {REGION_REPLICATION=>2}
> 2. write somerecords into 'testtable'
> 3. split the table 'testtable'
> 4. after the spliting, the serverHoldings in RegionStates still holds the 
> regioninfo for the replica of parent region
> 5. restart the regionserver where the parent regions lo[link 
> title|http://example.com]cated
> 6. the offlined replica of parent region will be assigned in 
> ServerCrashProcedure. 



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

[jira] [Created] (HBASE-18625) Splitting of region with replica, doesn't update region list in serverHolding.

[He Fei (JIRA)]

He Fei created HBASE-18625:
--

 Summary: Splitting of region with replica, doesn't update region 
list in serverHolding.
 Key: HBASE-18625
 URL: https://issues.apache.org/jira/browse/HBASE-18625
 Project: HBase
  Issue Type: Improvement
Affects Versions: 1.2.6
Reporter: He Fei
 Fix For: 1.2.7


The situation can appear in following steps in release hbase1.2.6

1. create 'testtable', 'info', {REGION_REPLICATION=>2}
2. write somerecords into 'testtable'
3. split the table 'testtable'
4. after the spliting, the serverHoldings in RegionStates still holds the 
regioninfo for the replica of parent region
5. restart the regionserver where the parent regions lo[link 
title|http://example.com]cated
6. the offlined replica of parent region will be assigned in 
ServerCrashProcedure. 





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

[jira] [Reopened] (HBASE-18489) Expose scan cursor in RawScanResultConsumer

[Duo Zhang (JIRA)]

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

Duo Zhang reopened HBASE-18489:
---

Revert some unnecessary changes...

> Expose scan cursor in RawScanResultConsumer
> ---
>
> Key: HBASE-18489
> URL: https://issues.apache.org/jira/browse/HBASE-18489
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 3.0.0, 2.0.0-alpha-1
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18489.patch, HBASE-18489-v1.patch, 
> HBASE-18489-v2.patch, HBASE-18489-v2.patch
>
>
> The first step of supporting scan cursor for async client.



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

[jira] [Updated] (HBASE-14498) Master stuck in infinite loop when all Zookeeper servers are unreachable

[stack (JIRA)]

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

stack updated HBASE-14498:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to branch-2 and master. Thank you for the patch [~pankaj_kumar]

> Master stuck in infinite loop when all Zookeeper servers are unreachable
> 
>
> Key: HBASE-14498
> URL: https://issues.apache.org/jira/browse/HBASE-14498
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Reporter: Y. SREENIVASULU REDDY
>Assignee: Pankaj Kumar
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14498.master.001.patch, 
> HBASE-14498.master.002.patch, HBASE-14498.patch, HBASE-14498-V2.patch, 
> HBASE-14498-V3.patch, HBASE-14498-V4.patch, HBASE-14498-V5.patch, 
> HBASE-14498-V6.patch, HBASE-14498-V6.patch
>
>
> We met a weird scenario in our production environment.
> In a HA cluster,
> > Active Master (HM1) is not able to connect to any Zookeeper server (due to 
> > N/w breakdown on master machine network with Zookeeper servers).
> {code}
> 2015-09-26 15:24:47,508 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 33463ms for sessionid 0x104576b8dda0002, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:24:47,877 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:48,236 INFO [main-SendThread(ZK-Host1:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host1 2181
> 2015-09-26 15:24:49,879 WARN 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:49,879 INFO 
> [HM1-Host:16000.activeMasterManager-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-IP1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:24:50,238 WARN [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host1
> 2015-09-26 15:24:50,238 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server 
> ZK-Host1/ZK-Host1:2181. Will not attempt to authenticate using SASL (unknown 
> error)
> 2015-09-26 15:25:17,470 INFO [main-SendThread(ZK-Host1:2181)] 
> zookeeper.ClientCnxn: Client session timed out, have not heard from server in 
> 30023ms for sessionid 0x2045762cc710006, closing socket connection and 
> attempting reconnect
> 2015-09-26 15:25:17,571 WARN [master/HM1-Host/HM1-IP:16000] 
> zookeeper.RecoverableZooKeeper: Possibly transient ZooKeeper, 
> quorum=ZK-Host:2181,ZK-Host1:2181,ZK-Host2:2181, 
> exception=org.apache.zookeeper.KeeperException$ConnectionLossException: 
> KeeperErrorCode = ConnectionLoss for /hbase/master
> 2015-09-26 15:25:17,872 INFO [main-SendThread(ZK-Host:2181)] 
> client.FourLetterWordMain: connecting to ZK-Host 2181
> 2015-09-26 15:25:19,874 WARN [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Can not get the principle name from server ZK-Host
> 2015-09-26 15:25:19,874 INFO [main-SendThread(ZK-Host:2181)] 
> zookeeper.ClientCnxn: Opening socket connection to server ZK-Host/ZK-IP:2181. 
> Will not attempt to authenticate using SASL (unknown error)
> {code}
> > Since HM1 was not able to connect to any ZK, so session timeout didnt 
> > happen at Zookeeper server side and HM1 didnt abort.
> > On Zookeeper session timeout standby master (HM2) registered himself as an 
> > active master. 
> > HM2 is keep on waiting for region server to report him as part of active 
> > master intialization.
> {noformat} 
> 2015-09-26 15:24:44,928 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 0 ms, 
> expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, interval 
> of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> ---
> ---
> 2015-09-26 15:32:50,841 | INFO | HM2-Host:21300.activeMasterManager | Waiting 
> for region servers count to settle; currently checked in 0, slept for 483913 
> ms, expecting minimum of 1, maximum of 2147483647, timeout of 4500 ms, 
> interval of 1500 ms. | 
> org.apache.hadoop.hbase.master.ServerManager.waitForRegionServers(ServerManager.java:1011)
> {noformat}
> > At other end, region servers are reporting to HM1 on 3 sec interval. Here 
> > region server retrieve master location from zookeeper only when they 
> > couldn't connect to Master (ServiceException).
> Region Server will not report HM2 as per current design until 

[jira] [Updated] (HBASE-18552) Backport the server side change in HBASE-18489 to branch-1

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-18552:
--
Assignee: Duo Zhang
  Status: Patch Available  (was: Open)

> Backport the server side change in HBASE-18489 to branch-1
> --
>
> Key: HBASE-18552
> URL: https://issues.apache.org/jira/browse/HBASE-18552
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-18552-branch-1.patch
>
>




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

[jira] [Updated] (HBASE-18552) Backport the server side change in HBASE-18489 to branch-1

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-18552:
--
Attachment: HBASE-18552-branch-1.patch

> Backport the server side change in HBASE-18489 to branch-1
> --
>
> Key: HBASE-18552
> URL: https://issues.apache.org/jira/browse/HBASE-18552
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Duo Zhang
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-18552-branch-1.patch
>
>




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

[jira] [Commented] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18617:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
38s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
30s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m  
7s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
32m 57s{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 
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
33s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}149m 22s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
31s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}210m 28s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | 
hadoop.hbase.security.access.TestCoprocessorWhitelistMasterObserver |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18617 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12882455/FuzzyRowFilter_HBASE_18617_1.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux a8657783e993 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31 
14:13:22 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 / 75a6b36 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8140/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8140/testReport/ |
| modules | C: hbase-client 

[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache

[Anoop Sam John (JIRA)]

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

Anoop Sam John commented on HBASE-18624:


So this is at the Replica cluster.  Again this should not be added as API/Shell 
in HBase directly.  For normal users this make no sense. This is some thing to 
be done internally by HBase. Here in replica cluster, there is no other go. So 
same CPEP way?  May be we can have a way?
You can expose this directly to the Admin or even u can have a CP running in 
the primary cluster and hooks after compaction, flush etc.  The CP code can use 
these EPs provided at the replica clusters to do the refresh of files or clear 
of BC.

> Added support for clearing BlockCache
> -
>
> 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: Ajay Jadhav
>Priority: Minor
> Fix For: 1.4.0
>
>
> 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-18298) RegionServerServices Interface cleanup for CP expose

[stack (JIRA)]

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

stack commented on HBASE-18298:
---

[~anoop.hbase] Let me look again. I don't like the RSSInternal thing. Let me 
see. Thanks for taking a look Anoop.

> RegionServerServices Interface cleanup for CP expose
> 
>
> Key: HBASE-18298
> URL: https://issues.apache.org/jira/browse/HBASE-18298
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, 
> HBASE-18298_V3.patch
>
>




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

[jira] [Created] (HBASE-18624) Added support for clearing BlockCache

[Ajay Jadhav (JIRA)]

Ajay Jadhav created HBASE-18624:
---

 Summary: Added support for clearing BlockCache
 Key: HBASE-18624
 URL: https://issues.apache.org/jira/browse/HBASE-18624
 Project: HBase
  Issue Type: Improvement
Affects Versions: 1.3.0, 2.0.0
Reporter: Ajay Jadhav
Assignee: Ajay Jadhav
Priority: Minor
 Fix For: 1.4.0


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-18619) Should we add a postOpenDeployTasks after open splited or merged region?

[Jingyun Tian (JIRA)]

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

Jingyun Tian commented on HBASE-18619:
--

[~apurtell] Could you pls check this out?

> Should we add a postOpenDeployTasks after open splited or merged region?
> 
>
> Key: HBASE-18619
> URL: https://issues.apache.org/jira/browse/HBASE-18619
> Project: HBase
>  Issue Type: Bug
>  Components: Region Assignment
>Affects Versions: 0.98.6, 1.4.0, 1.2.6, 1.1.11
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>
> I have a question that why we skip postOpenDeployTasks() when we not using zk 
> for assignment?
> {code:java}
>   if (services != null) {
> try {
>   if (useZKForAssignment) {
> // add 2nd daughter first (see HBASE-4335)
> services.postOpenDeployTasks(b);
>   } else if 
> (!services.reportRegionStateTransition(TransitionCode.SPLIT,
>   parent.getRegionInfo(), hri_a, hri_b)) {
> throw new IOException("Failed to report split region to master: "
>   + parent.getRegionInfo().getShortNameToLog());
>   }
>   // Should add it to OnlineRegions
>   services.addToOnlineRegions(b);
>   if (useZKForAssignment) {
> services.postOpenDeployTasks(a);
>   }
>   services.addToOnlineRegions(a);
> } catch (KeeperException ke) {
>   throw new IOException(ke);
> }
>   }
> {code}
> It causes a new splitted region or new merged region will not compact their 
> reference files. Then if the normalizer thread want to split this region, it 
> will get stuck. 
> {code:java}
> public boolean canSplit() {
> this.lock.readLock().lock();
> try {
>   // Not split-able if we find a reference store file present in the 
> store.
>   boolean result = !hasReferences();
>   if (!result && LOG.isDebugEnabled()) {
> LOG.debug("Cannot split region due to reference files being there");
>   }
>   return result;
> } finally {
>   this.lock.readLock().unlock();
> }
>   }
> {code}
> According to the code, should we add a  services.postOpenDeployTasks after 
> successfully _*reportRegionStateTransition(TransitionCode.SPLIT, 
> parent.getRegionInfo(), hri_a, hri_b)*_ ?



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

[jira] [Commented] (HBASE-15284) Make TimeRange constructors IA.Private and remove unused TimeRange constructors

[stack (JIRA)]

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

stack commented on HBASE-15284:
---

It looks like it a was a recent addition to Query:

tree a486ccc41bbeced25944f58ae8914c826b9219bb
parent 1eb24e4e8e8d2df4ba5cd3aa0223dfd08e1a90aa
author anoopsamjohn  Wed Dec 7 12:22:41 2016 +0530
committer anoopsamjohn  Wed Dec 7 12:22:41 2016 +0530

HBASE-17249 Get/Scan's setTimeRange/setColumnFamilyTimeRange can take the 
TimeRange reference as the parameter instead of creating a new 
setColumnFamilyTimeRange instance. (huaxiang sun)

Seems like it is only in hbase2 so far so you can change it since not in a 
release?

[~appy]



> Make TimeRange constructors IA.Private and remove unused TimeRange 
> constructors
> ---
>
> Key: HBASE-15284
> URL: https://issues.apache.org/jira/browse/HBASE-15284
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-15284.patch, hbase-15284.v2.patch, 
> hbase-15284.v3.patch
>
>




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

[jira] [Updated] (HBASE-18347) Implement a BufferedMutator for async client

[Duo Zhang (JIRA)]

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

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

Fix javadoc issues.

> Implement a BufferedMutator for async client
> 
>
> Key: HBASE-18347
> URL: https://issues.apache.org/jira/browse/HBASE-18347
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client
>Affects Versions: 3.0.0, 2.0.0-alpha-2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 3.0.0, 2.0.0-alpha-3
>
> Attachments: HBASE-18347.patch, HBASE-18347-v1.patch
>
>
> Need this if we want to replace the old implementation for sync client with 
> async client.



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

[jira] [Commented] (HBASE-15284) Make TimeRange constructors IA.Private and remove unused TimeRange constructors

[Appy (JIRA)]

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

Appy commented on HBASE-15284:
--

It's weird.
All constructor in are already marked deprecated in 2.0+. (HBASE-16176 
[~stack]; so the earlier patches here are obsolete)
The comment also says "Only used internally; should not be accessed directly by 
clients.".
But i see it being exposed to client: 
https://github.com/apache/hbase/blob/branch-2/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Query.java#L79
What's the deal here?


> Make TimeRange constructors IA.Private and remove unused TimeRange 
> constructors
> ---
>
> Key: HBASE-15284
> URL: https://issues.apache.org/jira/browse/HBASE-15284
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-15284.patch, hbase-15284.v2.patch, 
> hbase-15284.v3.patch
>
>




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

[jira] [Commented] (HBASE-18298) RegionServerServices Interface cleanup for CP expose

[Anoop Sam John (JIRA)]

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

Anoop Sam John commented on HBASE-18298:


[~stack]  You ok with this extended Interface ( for internal use) approach I 
believe. We have discussed abt its need.  Can u pls confirm? I will rebase the 
patch then.  Also pls suggest any better name for that Interface?  :-)

> RegionServerServices Interface cleanup for CP expose
> 
>
> Key: HBASE-18298
> URL: https://issues.apache.org/jira/browse/HBASE-18298
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, 
> HBASE-18298_V3.patch
>
>




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

[jira] [Commented] (HBASE-18623) Frequent failed to parse at EOF warnings from WALEntryStream

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-18623:
-

IIRC, this was added back when I was trying to get more information out of the 
replication system. The situation described is *probably* harmless, since we 
expect non-cleanly closed WALs to have unparseable partial entries. It's hard 
to say it's always fine, since we have yet to find the source of the corruption 
in HBASE-15983.

How about we move the message to DEBUG and expressly have it say that the 
failure to parse some data in an unclosed file is usually fine?

> Frequent failed to parse at EOF warnings from WALEntryStream
> 
>
> Key: HBASE-18623
> URL: https://issues.apache.org/jira/browse/HBASE-18623
> Project: HBase
>  Issue Type: Task
>Reporter: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
>
> Lots of messages like this
> {noformat}
> 2017-08-17 15:10:36,363 INFO
> [main-EventThread.replicationSource,2.replicationSource.replicationWALReaderThread.onyx%2C8120%2C1503007587035,2]
> regionserver.WALEntryStream: Reached the end of WAL file 
> 'hdfs://localhost:8020/hbase-1/WALs/onyx,8120,1503007587035/onyx%2C8120%2C1503007587035.1503007826083'.
> It was not closed cleanly, so we did not parse 8 bytes of data.
> {noformat}
> Fix this, either the message (if harmless) or the underlying cause. 



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

[jira] [Commented] (HBASE-18614) Setting BUCKET_CACHE_COMBINED_KEY to false disables stats on RS UI

[Anoop Sam John (JIRA)]

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

Anoop Sam John commented on HBASE-18614:


Patch LGTM.
So how it works when there is only L1 LRU cache in place. Which API been used? 
I did not check how this changed method is been used in UI code part. Just 
asking

> Setting BUCKET_CACHE_COMBINED_KEY to false disables stats on RS UI
> --
>
> Key: HBASE-18614
> URL: https://issues.apache.org/jira/browse/HBASE-18614
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 1.1.2
>Reporter: Biju Nair
>Assignee: Biju Nair
> Attachments: HBASE-18614-1.1.2.PATCH
>
>
> Enabling offheap cache and setting {{BUCKET_CACHE_COMBINED_KEY}} to {{false}} 
> in site xml to make offheap cache a strict L2 cache to LRU cache, disables 
> the L2 stats normally rendered on region server UI.  



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

[jira] [Commented] (HBASE-18615) hbase-rest tests fail in hbase-2.0.0-alpha2

[stack (JIRA)]

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

stack commented on HBASE-18615:
---

It looked like this: 
https://stackoverflow.com/questions/28509370/nosuchmethoderror-on-startup-in-java-jersey-app

The rest .out had similar complaint.

It turns out we are getting the javax.ws.rs.core.Application from old jersey 
transitively included from hadoop (figured it by passing verbose classloading 
to the start rest server).

Probably broke by  HBASE-12894 Upgrade to Jetty 9 for REST / Info Server /

Digging on how to update rest to jersey2

> hbase-rest tests fail in hbase-2.0.0-alpha2
> ---
>
> Key: HBASE-18615
> URL: https://issues.apache.org/jira/browse/HBASE-18615
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: stack
>
> Pointed out by Andrew on VOTE mail



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

[jira] [Updated] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha updated HBASE-18617:

Attachment: FuzzyRowFilter_HBASE_18617_1.patch

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
> Attachments: FuzzyRowFilter_HBASE_18617_1.patch
>
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18503:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 20 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
33s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
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} findbugs {color} | {color:green}  3m 
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
46s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
30m 22s{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 
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
33s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}120m 
12s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
34s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}174m 13s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.13.1 Server=1.13.1 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18503 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12882422/HBASE-18503.v2.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 4a16b6b735be 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7 
11:05:26 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 / 75a6b36 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8138/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8138/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Change ***Util and Master to use 

[jira] [Commented] (HBASE-18490) Modifying a table descriptor to enable replicas does not create replica regions

[huaxiang sun (JIRA)]

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

huaxiang sun commented on HBASE-18490:
--

Hi [~ram_krish], which version did you check? I ran this with branch-1.2 and it 
worked. Looked at the code,
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ModifyTableProcedure.java#L107

The handling of replica count change is there.


> Modifying a table descriptor to enable replicas does not create replica 
> regions
> ---
>
> Key: HBASE-18490
> URL: https://issues.apache.org/jira/browse/HBASE-18490
> Project: HBase
>  Issue Type: Bug
>  Components: Region Assignment
>Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: TestRegionReplicasWithRestartScenarios.java
>
>
> After creating a table, if we try to modify the table to enable region 
> replication, the new Htable Descriptor is not taken into account and the 
> table is enabled again with default single region.
> Ping [~enis], [~tedyu], [~devaraj].



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

[jira] [Updated] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha updated HBASE-18617:

Attachment: (was: FuzzyRowFilter_HBASE_18617.patch)

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Updated] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha updated HBASE-18617:

Attachment: (was: TestFuzzyRowFilterEndToEnd_HBASE_18617.patch)

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Issue Comment Deleted] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha updated HBASE-18617:

Comment: was deleted

(was: The test is failing with:
{noformat}
Error Message

expected: but was:
Stacktrace

java.lang.AssertionError: expected: but was:
at 
org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd.testAllFixedBits(TestFuzzyRowFilterEndToEnd.java:162)
{noformat}

It looks like my patch in `FuzzyRowFilter` is not used because the same test 
passes locally. Could anyone let me know how can I verify whether all the patch 
files were used by the build? )

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
> Attachments: FuzzyRowFilter_HBASE_18617.patch, 
> TestFuzzyRowFilterEndToEnd_HBASE_18617.patch
>
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Created] (HBASE-18623) Frequent failed to parse at EOF warnings from WALEntryStream

[Andrew Purtell (JIRA)]

Andrew Purtell created HBASE-18623:
--

 Summary: Frequent failed to parse at EOF warnings from 
WALEntryStream
 Key: HBASE-18623
 URL: https://issues.apache.org/jira/browse/HBASE-18623
 Project: HBase
  Issue Type: Task
Reporter: Andrew Purtell
 Fix For: 1.4.0, 1.5.0


Lots of messages like this

{noformat}
2017-08-17 15:10:36,363 INFO
[main-EventThread.replicationSource,2.replicationSource.replicationWALReaderThread.onyx%2C8120%2C1503007587035,2]
regionserver.WALEntryStream: Reached the end of WAL file 
'hdfs://localhost:8020/hbase-1/WALs/onyx,8120,1503007587035/onyx%2C8120%2C1503007587035.1503007826083'.
It was not closed cleanly, so we did not parse 8 bytes of data.
{noformat}

Fix this, either the message (if harmless) or the underlying cause. 



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

[jira] [Comment Edited] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha edited comment on HBASE-18617 at 8/17/17 10:14 PM:
---

The test is failing with:
{noformat}
Error Message

expected: but was:
Stacktrace

java.lang.AssertionError: expected: but was:
at 
org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd.testAllFixedBits(TestFuzzyRowFilterEndToEnd.java:162)
{noformat}

It looks like my patch in `FuzzyRowFilter` is not used because the same test 
passes locally. Could anyone let me know how can I verify whether all the patch 
files were used by the build? 


was (Author: vinishavyasa):
The test is failing with:
{noformat}
Error Message

expected: but was:
Stacktrace

java.lang.AssertionError: expected: but was:
at 
org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd.testAllFixedBits(TestFuzzyRowFilterEndToEnd.java:162)
{noformat}

It looks like my patch in `FuzzyRowFilter` is not used because the same test 
passes locally. Could anyone let me know how can I make sure whether all the 
patch files were used by the build? 

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
> Attachments: FuzzyRowFilter_HBASE_18617.patch, 
> TestFuzzyRowFilterEndToEnd_HBASE_18617.patch
>
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Commented] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[vinisha (JIRA)]

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

vinisha commented on HBASE-18617:
-

The test is failing with:
{noformat}
Error Message

expected: but was:
Stacktrace

java.lang.AssertionError: expected: but was:
at 
org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd.testAllFixedBits(TestFuzzyRowFilterEndToEnd.java:162)
{noformat}

It looks like my patch in `FuzzyRowFilter` is not used because the same test 
passes locally. Could anyone let me know how can I make sure whether all the 
patch files were used by the build? 

> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.1.2
>Reporter: vinisha
>Assignee: vinisha
>Priority: Minor
> Attachments: FuzzyRowFilter_HBASE_18617.patch, 
> TestFuzzyRowFilterEndToEnd_HBASE_18617.patch
>
>
> Current implementation of FuzzyRowKeyFilter modifies the provided filter 
> pairs: 
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FuzzyRowFilter.java#L89-L90
> Filter should not change the filter pair. 



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

[jira] [Commented] (HBASE-18617) FuzzyRowKeyFilter should not modify the filter pairs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18617:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
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 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  0m 
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
32m 37s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  3m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
37s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}114m 26s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
17s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 44s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18617 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12882419/TestFuzzyRowFilterEndToEnd_HBASE_18617.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 1fa9857b0c52 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 / 75a6b36 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8136/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8136/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8136/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> FuzzyRowKeyFilter should not modify the filter pairs
> 
>
> Key: HBASE-18617
> URL: https://issues.apache.org/jira/browse/HBASE-18617
> Project: HBase
>  

[jira] [Commented] (HBASE-16231) Integration tests should support client keytab login for secure clusters

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-16231:
-

Thanks for the release note Gary, that's great.

It sounds like the new keytab/principal configs aren't required. Is that 
correct?

> Integration tests should support client keytab login for secure clusters
> 
>
> Key: HBASE-16231
> URL: https://issues.apache.org/jira/browse/HBASE-16231
> Project: HBase
>  Issue Type: Improvement
>  Components: integration tests
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16231.001.patch
>
>
> Integration tests currently rely on an external kerberos login for secure 
> clusters.  Elsewhere we use AuthUtil to login and refresh the credentials in 
> a background thread.  We should do the same here.



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-18503:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
25s{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 20 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  5m 
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
58s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
39m 43s{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}  5m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
44s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 84m 52s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
55s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}154m 47s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | 
org.apache.hadoop.hbase.master.procedure.TestDisableTableProcedure |
|   | org.apache.hadoop.hbase.master.procedure.TestDeleteTableProcedure |
|   | org.apache.hadoop.hbase.master.procedure.TestModifyTableProcedure |
|   | org.apache.hadoop.hbase.master.procedure.TestCreateTableProcedure |
|   | org.apache.hadoop.hbase.regionserver.TestRowTooBig |
|   | org.apache.hadoop.hbase.regionserver.TestSplitLogWorker |
|   | org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy 
|
|   | org.apache.hadoop.hbase.master.TestGetLastFlushedSequenceId |
|   | org.apache.hadoop.hbase.regionserver.wal.TestFSHLog |
|   | org.apache.hadoop.hbase.regionserver.TestCompaction |
|   | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
|   | org.apache.hadoop.hbase.snapshot.TestSnapshotClientRetries |
|   | org.apache.hadoop.hbase.backup.TestRemoteBackup |
|   | org.apache.hadoop.hbase.regionserver.TestTimestampFilterSeekHint |
|   | org.apache.hadoop.hbase.TestHBaseTestingUtility |
|   | 

[jira] [Commented] (HBASE-11466) HConnectionImplementation should not use ZK

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov commented on HBASE-11466:
-

At the moment there's no work going on here...So I guess we kick it out of 2.0 
timeline?

> HConnectionImplementation should not use ZK
> ---
>
> Key: HBASE-11466
> URL: https://issues.apache.org/jira/browse/HBASE-11466
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client, Consensus
>Affects Versions: 2.0.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
>Priority: Critical
> Fix For: 2.0.0
>
>
> Currently ConnectionManager.HConnectionImplementation uses ZK to get address 
> of current master. Should instead use pluggable interface to get location of 
> master to connect to (current active master in the cluster, until we have 
> multiple active masters) elsewhere (e.g. round-robin over the list of masters 
> set in the client's hbase-site.xml).
> Currently it uses MasterAddressTracker, which reads from ZK, and this is the 
> only place where MasterAddressTracker is used on the client side (except 
> ZkUtil util method which dumps ZK namespace to log). So implementation of  
> failover proxy which fails over multiple masters will probably used only here.



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

[jira] [Updated] (HBASE-16231) Integration tests should support client keytab login for secure clusters

[Gary Helmling (JIRA)]

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

Gary Helmling updated HBASE-16231:
--
Release Note: Prior to this change, the integration test clients 
(IntegrationTest*) relied on the Kerberos credential cache for authentication 
against secured clusters.  This could lead to the tests failing due to 
authentication failures when the tickets in the credential cache expired.  With 
this change, the integration test clients will make use of the configuration 
properties for "hbase.client.keytab.file" and 
"hbase.client.kerberos.principal", when available.  This will perform a login 
from the configured keytab file and automatically refresh the credentials in 
the background for the process lifetime.

> Integration tests should support client keytab login for secure clusters
> 
>
> Key: HBASE-16231
> URL: https://issues.apache.org/jira/browse/HBASE-16231
> Project: HBase
>  Issue Type: Improvement
>  Components: integration tests
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16231.001.patch
>
>
> Integration tests currently rely on an external kerberos login for secure 
> clusters.  Elsewhere we use AuthUtil to login and refresh the credentials in 
> a background thread.  We should do the same here.



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

[jira] [Commented] (HBASE-14498) Master stuck in infinite loop when all Zookeeper servers are unreachable

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-14498:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 20m 
28s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
37s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m  
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  4m 
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
56s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
26s{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} hadoopcheck {color} | {color:green} 
34m 53s{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}  5m 
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  2m 
49s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}141m 
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
31s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}222m 58s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.0 Server=1.12.0 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-14498 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12882305/HBASE-14498.master.002.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 15bb17da6617 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 | master / 75a6b36 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| whitespace | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8135/artifact/patchprocess/whitespace-eol.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8135/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output | 

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18503:


bq. Leads to possibility of somebody making a silly but difficult to catch 
mistake in the future,
You are right. Adding a default equals() on interface is a bad design. Will 
remove it from next patch.

[~stack] Sorry for wasting your retry.

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-18503:
---

Oh, I think I posed my question backwards, then! I know we have to have 
equals(Object) because that's what Java makes us do. Why do we have equals(TD) 
is what I don't understand? Leads to possibility of somebody making a silly but 
difficult to catch mistake in the future, IMO.

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-18503:


bq. I was pretty sure that always called the object form
Ya, that is why we need the HTD#equals(object). The TD#equals(TD) won't be 
called by assertEquals. 

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-18601) Remove Htrace 3.2

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-18601:
-

Regardless of the outcome for HTrace in HBase, it sounds like we should call 
out tracing in our compatibility concerns section on versioning.

> Remove Htrace 3.2
> -
>
> Key: HBASE-18601
> URL: https://issues.apache.org/jira/browse/HBASE-18601
> Project: HBase
>  Issue Type: Task
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Tamas Penzes
>Assignee: Andrew Purtell
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18601.master.001.patch
>
>
> HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, 
> the upgrade to 4.x is not trivial and would take time. It might not worth to 
> keep it in this state, so would be better to remove it.
> Of course it doesn't mean tracing would be useless, just that in this form 
> the use of HTrace 3.2 might not add any value to the project and fixing it 
> would be far too much effort.



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-18503:
---

don't take this as blocking commit, btw. we can continue to discuss with or 
without the patch, since that code is already in there and not new.

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-18503:
---

assertEquals() as in from junit? I was pretty sure that always called the 
object form, no?

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-15284) Make TimeRange constructors IA.Private and remove unused TimeRange constructors

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15284:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-15284 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-15284 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12788702/hbase-15284.v3.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/8139/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Make TimeRange constructors IA.Private and remove unused TimeRange 
> constructors
> ---
>
> Key: HBASE-15284
> URL: https://issues.apache.org/jira/browse/HBASE-15284
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-15284.patch, hbase-15284.v2.patch, 
> hbase-15284.v3.patch
>
>




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

[jira] [Commented] (HBASE-18577) shaded client includes several non-relocated third party dependencies

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-18577:
---

retargetting to alpha-3 in anticipation that the current alpha2 vote passes. if 
the vote fails and this makes it into the next rc, please update jira 
appropriately.

> shaded client includes several non-relocated third party dependencies
> -
>
> Key: HBASE-18577
> URL: https://issues.apache.org/jira/browse/HBASE-18577
> Project: HBase
>  Issue Type: Bug
>  Components: Client
>Affects Versions: 1.2.0, 1.1.2, 1.3.0, 2.0.0-alpha-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-3, 1.1.13
>
> Attachments: HBASE-18577.WIP.0.patch, HBASE-18577.WIP.-1.patch, 
> HBASE-18577.WIP.1.patch
>
>
> we have some unexpected unrelocated third party dependencies in our shaded 
> artifacts.



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

[jira] [Updated] (HBASE-18577) shaded client includes several non-relocated third party dependencies

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18577:
--
Fix Version/s: (was: 2.0.0-alpha-2)
   2.0.0-alpha-3

> shaded client includes several non-relocated third party dependencies
> -
>
> Key: HBASE-18577
> URL: https://issues.apache.org/jira/browse/HBASE-18577
> Project: HBase
>  Issue Type: Bug
>  Components: Client
>Affects Versions: 1.2.0, 1.1.2, 1.3.0, 2.0.0-alpha-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-3, 1.1.13
>
> Attachments: HBASE-18577.WIP.0.patch, HBASE-18577.WIP.-1.patch, 
> HBASE-18577.WIP.1.patch
>
>
> we have some unexpected unrelocated third party dependencies in our shaded 
> artifacts.



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

[jira] [Updated] (HBASE-18601) Remove Htrace 3.2

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18601:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Remove Htrace 3.2
> -
>
> Key: HBASE-18601
> URL: https://issues.apache.org/jira/browse/HBASE-18601
> Project: HBase
>  Issue Type: Task
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Tamas Penzes
>Assignee: Andrew Purtell
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18601.master.001.patch
>
>
> HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, 
> the upgrade to 4.x is not trivial and would take time. It might not worth to 
> keep it in this state, so would be better to remove it.
> Of course it doesn't mean tracing would be useless, just that in this form 
> the use of HTrace 3.2 might not add any value to the project and fixing it 
> would be far too much effort.



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

[jira] [Updated] (HBASE-13740) Stop using Hadoop private interfaces

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-13740:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Stop using Hadoop private interfaces
> 
>
> Key: HBASE-13740
> URL: https://issues.apache.org/jira/browse/HBASE-13740
> Project: HBase
>  Issue Type: Umbrella
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Now that we are push downstream folks to stay off of our private interfaces, 
> we should provide a good example by doing the same with Hadoop.
> Things to do in this umbrella
> * We need a good way to check; manual inspection is untenable
> * For anything where Hadoop isn't maintaining an isolated API (i.e. they 
> include a non-org.apache.hadoop or jvm class), we should just rip things out
> * For the rest we'll need to determine if we ask for upgrading things to 
> LimitedPrivate(HBase) or Public 



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

[jira] [Updated] (HBASE-14997) Move compareOp and Comparators out of filter to client package

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-14997:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Move compareOp and Comparators out of filter to client package
> --
>
> Key: HBASE-14997
> URL: https://issues.apache.org/jira/browse/HBASE-14997
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> {{Table.checkAndPut()}} and its cousins depend on CompareOp from the filter 
> package. Originally, ComparaOp and ByteArrayComparable, and various 
> "comparators" have been used in filters, so these are in the filter package. 
> However, for checkAndPut(), etc we depend on the filter subpackage although 
> these are not filter related operations. We can use some clean up.
> {code}
>   boolean checkAndPut(byte[] row, byte[] family, byte[] qualifier,
> CompareFilter.CompareOp compareOp, byte[] value, Put put) throws 
> IOException;
> {code}
> Some ideas
>  - Cleanup ByteArrayComparable interface (see the TODO at the class) 
>  - Maybe introduce a {{Condition}} or a similar concept and do 
> {{checkAndPut(Condition condition, Put put)}} and change filters to use that 
> as well. 
>  - Introducing Condition like thing will allow us to have an interface like: 
> {{checkAndMutate(List conditions, List mutations)}}. 
>  - BinaryComparator, etc are not "Comparators", they are comparables. 



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

[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-13346:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Clean up Filter package for post 1.0
> 
>
> 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
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> 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-14255) Simplify Cell creation post 1.0

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-14255:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Simplify Cell creation post 1.0
> ---
>
> Key: HBASE-14255
> URL: https://issues.apache.org/jira/browse/HBASE-14255
> Project: HBase
>  Issue Type: Improvement
>  Components: Client
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Lars George
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> After the switch to the new Cell based client API, and making KeyValue 
> private (but especially as soon as DBB backed Cells land) it is rather 
> difficult to create a {{Cell}} instance. I am using this now:
> {code}
>  @Override
>   public void postGetOp(ObserverContext e,
> Get get, List results) throws IOException {
> Put put = new Put(get.getRow());
> put.addColumn(get.getRow(), FIXED_COLUMN, Bytes.toBytes(counter.get()));
> CellScanner scanner = put.cellScanner();
> scanner.advance();
> Cell cell = scanner.current();
> LOG.debug("Adding fake cell: " + cell);
> results.add(cell);
>   }
> {code}
> That is, I have to create a {{Put}} instance to add a cell and then retrieve 
> its instance. The {{KeyValue}} methods are private now and should not be 
> used. Create a CellBuilder helper?



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

[jira] [Updated] (HBASE-13271) Table#puts(List) operation is indeterminate; needs fixing

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-13271:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Table#puts(List) operation is indeterminate; needs fixing
> --
>
> Key: HBASE-13271
> URL: https://issues.apache.org/jira/browse/HBASE-13271
> Project: HBase
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 1.0.0
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> Another API issue found by [~larsgeorge]:
> "Table.put(List {code}
> [Mar-17 9:21 AM] Lars George: Table.put(List) is weird since you cannot 
> flush partial lists
> [Mar-17 9:21 AM] Lars George: Say out of 5 the third is broken, then the 
> put() call returns with a local exception (say empty Put) and then you have 2 
> that are in the buffer
> [Mar-17 9:21 AM] Lars George: but how to you force commit them?
> [Mar-17 9:22 AM] Lars George: In the past you would call flushCache(), but 
> that is "gone" now
> [Mar-17 9:22 AM] Lars George: and flush() is not available on a Table
> [Mar-17 9:22 AM] Lars George: And you cannot access the underlying 
> BufferedMutation neither
> [Mar-17 9:23 AM] Lars George: You can *only* add more Puts if you can, or 
> call close()
> [Mar-17 9:23 AM] Lars George: that is just weird to explain
> {code}
> So, Table needs to get flush back or we deprecate this method or it flushes 
> immediately and does not return until complete in the implementation.



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

[jira] [Updated] (HBASE-10944) Remove all kv.getBuffer() and kv.getRow() references existing in the code

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-10944:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Remove all kv.getBuffer() and kv.getRow() references existing in the code
> -
>
> Key: HBASE-10944
> URL: https://issues.apache.org/jira/browse/HBASE-10944
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 1.5.0, 2.0.0-alpha-3
>
>
> kv.getRow() and kv.getBuffers() are still used in places to form key byte[] 
> and row byte[].  Removing all such instances including testcases will make 
> the usage of Cell complete.



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

[jira] [Updated] (HBASE-15284) Make TimeRange constructors IA.Private and remove unused TimeRange constructors

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-15284:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Make TimeRange constructors IA.Private and remove unused TimeRange 
> constructors
> ---
>
> Key: HBASE-15284
> URL: https://issues.apache.org/jira/browse/HBASE-15284
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-15284.patch, hbase-15284.v2.patch, 
> hbase-15284.v3.patch
>
>




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

[jira] [Updated] (HBASE-18169) Coprocessor fix and cleanup before 2.0.0 release

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18169:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Coprocessor fix and cleanup before 2.0.0 release
> 
>
> Key: HBASE-18169
> URL: https://issues.apache.org/jira/browse/HBASE-18169
> Project: HBase
>  Issue Type: Improvement
>  Components: Coprocessors
>Affects Versions: 2.0.0-alpha-1
>Reporter: Duo Zhang
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> As discussed in HBASE-18038. In RegionServerServices, Region and StoreFile 
> interfaces we expose too many unnecessary methods. We need to find a way to 
> not expose these methods to CP.



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

[jira] [Updated] (HBASE-16769) Deprecate/remove PB references from MasterObserver and RegionServerObserver

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-16769:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Deprecate/remove PB references from MasterObserver and RegionServerObserver
> ---
>
> Key: HBASE-16769
> URL: https://issues.apache.org/jira/browse/HBASE-16769
> Project: HBase
>  Issue Type: Bug
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> This is effectively a sub-task for HBASE-15174.
> CP Methods
> MasterObserver
>   preListSnapshot
>   postListSnapshot
>   preSnapshot
>   postSnapshot
>   preCloneSnapshot
>   postCloneSnapshot
>   preRestoreSnapshot
>   postRestoreSnapshot
>   preDeleteSnapshot
>   postDeleteSnapshot
>   
>   preSetUserQuota
>   postSetUserQuota
>   preSetUserQuota
>   postSetUserQuota
>   preSetUserQuota
>   postSetUserQuota
>   preSetTableQuota
>   postSetTableQuota
>   preSetNamespaceQuota
>   postSetNamespaceQuota
>   
> RegionServerObserver
>   preReplicateLogEntries
>   postReplicateLogEntries



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

[jira] [Updated] (HBASE-18298) RegionServerServices Interface cleanup for CP expose

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18298:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> RegionServerServices Interface cleanup for CP expose
> 
>
> Key: HBASE-18298
> URL: https://issues.apache.org/jira/browse/HBASE-18298
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, 
> HBASE-18298_V3.patch
>
>




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

[jira] [Updated] (HBASE-9417) SecureBulkLoadEndpoint should be folded in core

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-9417:
-
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> SecureBulkLoadEndpoint should be folded in core
> ---
>
> Key: HBASE-9417
> URL: https://issues.apache.org/jira/browse/HBASE-9417
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver, security
>Reporter: Enis Soztutar
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
>
> In unsecure bulk loading, the client creates the files to be bulk loaded, and 
> asks the regionservers to do the operation. Bulk loading is performed by a 
> move, which would mean that the hbase user has to have WRITE permissions for 
> the bulk loaded files. If the client who has generated the files is different 
> than the hbase user, this creates an access denied exception if complete bulk 
> load is not run as the hbase user.
> I think even for unsecure mode, we should mimic what SecureBulkLoadEndpoint 
> does, where hbase creates a staging directory and the client hands off the 
> files to that directory with global perms. 
> Update: Now that HBASE-12052 enables running SecureBulkLoadEndpoint even in 
> unsecure deployments, we should consider bringing SecureBulkLoad into core 
> HBase (meaning implement the functionality in RegionServer instead of in the 
> coprocessor). 



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

[jira] [Updated] (HBASE-17143) Scan improvement

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-17143:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Scan improvement
> 
>
> Key: HBASE-17143
> URL: https://issues.apache.org/jira/browse/HBASE-17143
> Project: HBase
>  Issue Type: Umbrella
>  Components: Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Parent issues to track some improvements of the current scan.
> Timeout per scan, unify batch and allowPartial, add inclusive and exclusive 
> of startKey and endKey, start scan from the middle of a record, use mvcc to 
> keep row atomic when allowPartial, etc.



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

[jira] [Updated] (HBASE-18596) A hbase1 cluster should be able to replicate to a hbase2 cluster; verify

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18596:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> A hbase1 cluster should be able to replicate to a hbase2 cluster; verify
> 
>
> Key: HBASE-18596
> URL: https://issues.apache.org/jira/browse/HBASE-18596
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Assignee: Esteban Gutierrez
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> From the mailing list thread "[DISCUSS] hbase-2.0.0 compatibility 
> expectations", [~esteban] asks:
> bq. Should we add additional details around replication as well? for 
> instance, shall we consider a hbase-1.x cluster as a client for a hbase-2.x 
> cluster?
> The latter should be a blocker. Verify it works.



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

[jira] [Updated] (HBASE-18106) Redo ProcedureInfo and LockInfo

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18106:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Redo ProcedureInfo and LockInfo
> ---
>
> Key: HBASE-18106
> URL: https://issues.apache.org/jira/browse/HBASE-18106
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: stack
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-3
>
> Attachments: HBASE-18106.master.001.patch, 
> HBASE-18106.master.002.patch, HBASE-18106.master.003.patch
>
>
> ProcedureInfo was introduced as a lowest-common-denominator POJO that could 
> be used as a facade on PB Procedures. It was good for showing state of 
> Procedure framework in shell and UI.
> Its a bit weird though. Its up in hbase-common rather than in Procedure and 
> it can only ever show a subset of the Procedure info.
> I was thinking we could use the pb3.1 pb->JSON utility instead and emit a 
> JSON String wherever we need to export a view on procedure internals.
> This issue is about exploring this possibility. Would depend on our having an 
> upgraded guava (so probably depends on the 'pre-build' project).
> From ProcedureInfo and LockInfo need fixing in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.kid1jzo114xw



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

[jira] [Updated] (HBASE-17442) Move most of the replication related classes to hbase-server package

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-17442:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Move most of the replication related classes to hbase-server package
> 
>
> Key: HBASE-17442
> URL: https://issues.apache.org/jira/browse/HBASE-17442
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Replication
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-3
>
> Attachments: 0001-hbase-replication-module.patch, 
> HBASE-17442.v1.patch, HBASE-17442.v2.patch, HBASE-17442.v2.patch, 
> HBASE-17442.v3.patch
>
>
> After the replication requests are routed through master, replication 
> implementation details didn't need be exposed to client. We should move most 
> of the replication related classes to hbase-server package.



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

[jira] [Updated] (HBASE-16550) Procedure v2 - Add AM compatibility for 2.x Master and 1.x RSs; i.e. support Rolling Upgrade from hbase-1 to -2.

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-16550:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Procedure v2 - Add AM compatibility for 2.x Master and 1.x RSs; i.e. support 
> Rolling Upgrade from hbase-1 to -2.
> 
>
> Key: HBASE-16550
> URL: https://issues.apache.org/jira/browse/HBASE-16550
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2, Region Assignment
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Core AM HBASE-14614 relies on the RS to be using zkless assignment. Add 
> support for the old a plain non zkless AM



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

[jira] [Updated] (HBASE-16060) 1.x clients cannot access table state talking to 2.0 cluster

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-16060:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> 1.x clients cannot access table state talking to 2.0 cluster
> 
>
> Key: HBASE-16060
> URL: https://issues.apache.org/jira/browse/HBASE-16060
> Project: HBase
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Since table state is migrated to meta instead of zk in 2.0, 1.x clients 
> talking to 2.0 cluster cannot access the table state. This causes some weird 
> behavior since from a client perspective, {{Admin.isTableEnabled()}} and 
> {{Admin.isTableDisabled()}} both return false. 
> One option we can do is to add code in 1.x clients so that they can access 
> the table state in meta if needed. Otherwise, we can mirror the table state 
> in zk (while keeping meta as the source of truth) during 2.x lifecycle so 
> that any 1.x client can still work correctly. 



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

[jira] [Updated] (HBASE-14998) Unify synchronous and asynchronous methods in Admin and cleanup

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-14998:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Unify synchronous and asynchronous methods in Admin and cleanup
> ---
>
> Key: HBASE-14998
> URL: https://issues.apache.org/jira/browse/HBASE-14998
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Admin has a bunch of methods, some are asnyc, some are sync. Needs some 
> unification in method naming, and method signatures. 
>  - We use modify and alter interchangeably. Pick one and stick with it 
> (modifyTable(), versus getAlterStatus()). Shell uses {{alter}}. 
>  - Remove getAlterStatus(), should not be needed. 
>  - remove already deprecated methods 
>  -  isTableAvailable(TableName tableName, byte[][] splitKeys) should be 
> removed. 
>  - Consistently use Aysnc as a prefix for all async methods. 
>  - Other ideas? 



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

[jira] [Updated] (HBASE-14996) Some more API cleanup for 2.0

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-14996:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Some more API cleanup for 2.0 
> --
>
> Key: HBASE-14996
> URL: https://issues.apache.org/jira/browse/HBASE-14996
> Project: HBase
>  Issue Type: Improvement
>Reporter: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> Parent jira to keep track of some more API cleanup that did not happen in 1.x 
> timeframe. 



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

[jira] [Updated] (HBASE-15982) Interface ReplicationEndpoint extends Guava's Service

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-15982:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Interface ReplicationEndpoint extends Guava's Service
> -
>
> Key: HBASE-15982
> URL: https://issues.apache.org/jira/browse/HBASE-15982
> Project: HBase
>  Issue Type: Bug
>Reporter: Andrew Purtell
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
> Attachments: HBASE-15982.master.001.patch
>
>
> We have Guava's Service leaking into the LimitedPrivate interface 
> ReplicationEndpoint:
> {code}
> public interface ReplicationEndpoint extends Service, 
> ReplicationPeerConfigListener
> {code}
> This required a private patch when I updated Guava for our internal 
> deployments. This is going to be a problem for us for long term maintenance 
> and implenters of pluggable replication endpoints. LP is only less than 
> public by a degree. We shouldn't leak types from third part code into either 
> Public or LP APIs in my opinion. Let's fix.



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

[jira] [Updated] (HBASE-10504) Define Replication Interface

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-10504:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Define Replication Interface
> 
>
> Key: HBASE-10504
> URL: https://issues.apache.org/jira/browse/HBASE-10504
> Project: HBase
>  Issue Type: Task
>  Components: Replication
>Reporter: stack
>Assignee: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-10504_v1.patch, hbase-10504_wip1.patch
>
>
> HBase has replication.  Fellas have been hijacking the replication apis to do 
> all kinds of perverse stuff like indexing hbase content (hbase-indexer 
> https://github.com/NGDATA/hbase-indexer) and our [~toffer] just showed up w/ 
> overrides that replicate via an alternate channel (over a secure thrift 
> channel between dcs over on HBASE-9360).  This issue is about surfacing these 
> APIs as public with guarantees to downstreamers similar to those we have on 
> our public client-facing APIs (and so we don't break them for downstreamers).
> Any input [~phunt] or [~gabriel.reid] or [~toffer]?
> Thanks.
>  



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

[jira] [Updated] (HBASE-10462) Recategorize some of the client facing Public / Private interfaces

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-10462:
--
Fix Version/s: (was: 2.0.0)
   2.0.0-alpha-3

> Recategorize some of the client facing Public / Private interfaces
> --
>
> Key: HBASE-10462
> URL: https://issues.apache.org/jira/browse/HBASE-10462
> Project: HBase
>  Issue Type: Bug
>  Components: Client
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
> Attachments: hbase-10462_wip1.patch
>
>
> We should go over the list of InterfaceAudience.Public interfaces one more to 
> remove those that are NOT indeed public interfaces. 
> From current trunk, we should change these from public to private: 
> {code}
> ReversedScannerCallable
> ReversedClientScanner
> ClientScanner  (note that ResultScanner is public interface, while 
> ClientScanner should not be) 
> ClientSmallScanner
> TableSnapshotScanner -> We need a way of constructing this since it cannot be 
> constructed from HConnection / HTable. Maybe a basic factory. 
> {code}
> These are not marked: 
> {code}
> Registry, 
> ZooKeeperRegistry
> RpcRetryingCallerFactory
> ZooKeeperKeepAliveConnection
> AsyncProcess
> DelegatingRetryingCallable
> HConnectionKey
> MasterKeepAliveConnection
> MultiServerCallable
> {code}
> We can think about making these public interface: 
> {code}
> ScanMetrics
> {code}
> Add javadoc to: 
> {code}
> Query
> {code}
> We can add a test to find out all classes in client package to check for 
> interface mark. 
> We can extend this to brainstorm on the preferred API options. We probably 
> want the clients to use HTableInterface, instead of HTable everywhere. 
> HConnectionManager comes with bazillion methods which are not intended for 
> public use, etc. 
> Raising this as blocker to 1.0



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

[jira] [Updated] (HBASE-18622) Mitigate compatibility concerns between branch-1 and branch-2

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-18622:
--
Fix Version/s: 2.0.0-alpha-3

> Mitigate compatibility concerns between branch-1 and branch-2
> -
>
> Key: HBASE-18622
> URL: https://issues.apache.org/jira/browse/HBASE-18622
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-alpha-3
>
>
> This project is to do what [~apurtell] did in the issue "HBASE-18431 Mitigate 
> compatibility concerns between branch-1.3 and branch-1.4" only do it between 
> branch-1 and branch-2.



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

[jira] [Updated] (HBASE-14716) Detection of orphaned table znode should cover table in Enabled state

[Ted Yu (JIRA)]

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

Ted Yu updated HBASE-14716:
---
Attachment: 14716.branch-1.v4.txt

> Detection of orphaned table znode should cover table in Enabled state
> -
>
> Key: HBASE-14716
> URL: https://issues.apache.org/jira/browse/HBASE-14716
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>  Labels: hbck
> Attachments: 14716-branch-1-v1.txt, 14716.branch-1.v4.txt
>
>
> HBASE-12070 introduced fix for orphaned table znode where table doesn't have 
> entry in hbase:meta
> When Stephen and I investigated rolling upgrade failure,
> {code}
> 2015-10-27 18:21:10,668 WARN  [ProcedureExecutorThread-3] 
> procedure.CreateTableProcedure: The table smoketest does not exist in meta 
> but has a znode. run hbck to fix inconsistencies.
> {code}
> we found that the orphaned table znode corresponded to table in Enabled state.
> Therefore running hbck didn't report the inconsistency.
> Detection for orphaned table znode should cover this case.



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

[jira] [Updated] (HBASE-18614) Setting BUCKET_CACHE_COMBINED_KEY to false disables stats on RS UI

[Biju Nair (JIRA)]

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

Biju Nair updated HBASE-18614:
--
Description: Enabling offheap cache and setting 
{{BUCKET_CACHE_COMBINED_KEY}} to {{false}} in site xml to make offheap cache a 
strict L2 cache to LRU cache, disables the L2 stats normally rendered on region 
server UI.(was: Enabling offheap cache and setting 
{{BUCKET_CACHE_COMBINED_KEY}} to {{false}} in site xml to make offheap cache a 
strict L2 cache to LRU cache, disables the L2 stats normally rendered on region 
sesrver UI.  )

> Setting BUCKET_CACHE_COMBINED_KEY to false disables stats on RS UI
> --
>
> Key: HBASE-18614
> URL: https://issues.apache.org/jira/browse/HBASE-18614
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 1.1.2
>Reporter: Biju Nair
>Assignee: Biju Nair
> Attachments: HBASE-18614-1.1.2.PATCH
>
>
> Enabling offheap cache and setting {{BUCKET_CACHE_COMBINED_KEY}} to {{false}} 
> in site xml to make offheap cache a strict L2 cache to LRU cache, disables 
> the L2 stats normally rendered on region server UI.  



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

[jira] [Created] (HBASE-18622) Mitigate compatibility concerns between branch-1 and branch-2

[stack (JIRA)]

stack created HBASE-18622:
-

 Summary: Mitigate compatibility concerns between branch-1 and 
branch-2
 Key: HBASE-18622
 URL: https://issues.apache.org/jira/browse/HBASE-18622
 Project: HBase
  Issue Type: Bug
  Components: API
Reporter: stack
Assignee: stack
Priority: Blocker


This project is to do what [~apurtell] did in the issue "HBASE-18431 Mitigate 
compatibility concerns between branch-1.3 and branch-1.4" only do it between 
branch-1 and branch-2.



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

[jira] [Updated] (HBASE-18503) Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor

[stack (JIRA)]

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

stack updated HBASE-18503:
--
Attachment: HBASE-18503.v2.patch

> Change ***Util and Master to use TableDescriptor and ColumnFamilyDescriptor
> ---
>
> Key: HBASE-18503
> URL: https://issues.apache.org/jira/browse/HBASE-18503
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-18503.v0.patch, HBASE-18503.v1.patch, 
> HBASE-18503.v1.patch, HBASE-18503.v2.patch, HBASE-18503.v2.patch, 
> HBASE-18503.v2.patch
>
>
> These helper classes accept the HTD and HCD as argument. We need to make some 
> changes for them, otherwise we will be forced to use HTD and HCD.
> # SecureTestUtil
> # MobSnapshotTestingUtils
> # HMaster



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

[jira] [Commented] (HBASE-17994) Add async client test to Performance Evaluation tool

[Hudson (JIRA)]

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

Hudson commented on HBASE-17994:


FAILURE: Integrated in Jenkins build HBASE-14070.HLC #233 (See 
[https://builds.apache.org/job/HBASE-14070.HLC/233/])
HBASE-17994 Add async client test to Performance Evaluation tool (zghao: rev 
2a9cdd5e75ab6e51e9ca0539caba29cc4350b98e)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java


> Add async client test to Performance Evaluation tool
> 
>
> Key: HBASE-17994
> URL: https://issues.apache.org/jira/browse/HBASE-17994
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-17994.master.001.patch, 
> HBASE-17994.master.002.patch, HBASE-17994.master.003.patch
>
>




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

[jira] [Commented] (HBASE-18375) The pool chunks from ChunkCreator are deallocated while in pool because there is no reference to them

[Hudson (JIRA)]

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

Hudson commented on HBASE-18375:


FAILURE: Integrated in Jenkins build HBASE-14070.HLC #233 (See 
[https://builds.apache.org/job/HBASE-14070.HLC/233/])
HBASE-18375: Fix the bug where the pool chunks from ChunkCreator are (anastas: 
rev 75a6b36849c58d6a751f57226ab0c8f7884a9e87)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactionPipeline.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemstoreLABWithoutPool.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemStoreLAB.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/MemStoreLABImpl.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ChunkCreator.java


> The pool chunks from ChunkCreator are deallocated while in pool because there 
> is no reference to them
> -
>
> Key: HBASE-18375
> URL: https://issues.apache.org/jira/browse/HBASE-18375
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0-alpha-1
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch, 
> HBASE-18375-V03.patch, HBASE-18375-V04.patch, HBASE-18375-V05.patch, 
> HBASE-18375-V06.patch, HBASE-18375-V07.patch, HBASE-18375-V08.patch, 
> HBASE-18375-V09.patch, HBASE-18375-V10.patch, HBASE-18375-V11.patch
>
>
> Because MSLAB list of chunks was changed to list of chunk IDs, the chunks 
> returned back to pool can be deallocated by JVM because there is no reference 
> to them. The solution is to protect pool chunks from GC by the strong map of 
> ChunkCreator introduced by HBASE-18010. Will prepare the patch today.



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

[jira] [Commented] (HBASE-18493) [AMv2] On region server crash do not process system table regions through AssignmentManager.checkIfShouldMoveSystemRegionAsync()

[Hudson (JIRA)]

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

Hudson commented on HBASE-18493:


FAILURE: Integrated in Jenkins build HBASE-14070.HLC #233 (See 
[https://builds.apache.org/job/HBASE-14070.HLC/233/])
HBASE-18493 [AMv2] Skipped re-assignment of regions on crashed server (stack: 
rev acf9b87dca2cd190f4b5318efd5dc48e19b317f4)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java


> [AMv2] On region server crash do not process system table regions through 
> AssignmentManager.checkIfShouldMoveSystemRegionAsync()
> 
>
> Key: HBASE-18493
> URL: https://issues.apache.org/jira/browse/HBASE-18493
> Project: HBase
>  Issue Type: Bug
>  Components: amv2
>Affects Versions: 2.0.0
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: hbase-18493.master.001.patch
>
>
> On Region Server crash, as ServerCrashProcedure handles reassignment of all 
> the regions on a crashed server, don't process those regions through 
> AssignmentManager.checkIfShouldMoveSystemRegionAsync(). This avoids duplicate 
> and makes ServerCrashProcedure as one place to find all related code for 
> handling server crash.



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

[jira] [Commented] (HBASE-18437) Revoke access permissions of a user from a table does not work as expected

[Hudson (JIRA)]

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

Hudson commented on HBASE-18437:


FAILURE: Integrated in Jenkins build HBASE-14070.HLC #233 (See 
[https://builds.apache.org/job/HBASE-14070.HLC/233/])
HBASE-18437 Revoke access permissions of a user from a table does not 
(apurtell: rev b0878184a31804a4bf061df7581964157b4849d5)
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/security/access/Permission.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java


> Revoke access permissions of a user from a table does not work as expected
> --
>
> Key: HBASE-18437
> URL: https://issues.apache.org/jira/browse/HBASE-18437
> Project: HBase
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.1.12
>Reporter: Ashish Singhi
>Assignee: Ashish Singhi
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0
>
> Attachments: HBASE-18437.patch, HBASE-18437-v1.patch
>
>
> A table for which a user was granted 'RW' permission. Now when we want to 
> revoke its 'W' permission only, code removes the user itself from that table 
> permissions.
> Below is the test code which reproduces the issue.
> {noformat}
> @Test(timeout = 18)
>   public void testRevokeOnlySomePerms() throws Throwable {
> TableName name = TableName.valueOf("testAgain");
> HTableDescriptor htd = new HTableDescriptor(name);
> HColumnDescriptor hcd = new HColumnDescriptor("cf");
> htd.addFamily(hcd);
> createTable(TEST_UTIL, htd);
> TEST_UTIL.waitUntilAllRegionsAssigned(name);
> try (Connection conn = ConnectionFactory.createConnection(conf)) {
>   AccessControlClient.grant(conn, name, USER_RO.getShortName(), null, 
> null, Action.READ, Action.WRITE);
>   ListMultimap tablePermissions = 
> AccessControlLists.getTablePermissions(conf, name);
>   // hbase user and USER_RO has permis
>   assertEquals(2, tablePermissions.size());
>   AccessControlClient.revoke(conn, name, USER_RO.getShortName(), null, 
> null, Action.WRITE);
>   tablePermissions = AccessControlLists.getTablePermissions(conf, name);
>   List userPerm = 
> tablePermissions.get(USER_RO.getShortName());
>   assertEquals(1, userPerm.size());
> } finally {
>   deleteTable(TEST_UTIL, name);
> }
>   }
> {noformat}



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