[jira] [Reopened] (HBASE-23595) HMaster abort when write to meta failed

[Esteban Gutierrez (Jira)]

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

Esteban Gutierrez reopened HBASE-23595:
---

> HMaster abort when write to meta failed
> ---
>
> Key: HBASE-23595
> URL: https://issues.apache.org/jira/browse/HBASE-23595
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Lijin Bin
>Priority: Major
>
> RegionStateStore
> {code}
>   private void updateRegionLocation(RegionInfo regionInfo, State state, Put 
> put)
>   throws IOException {
> try (Table table = 
> master.getConnection().getTable(TableName.META_TABLE_NAME)) {
>   table.put(put);
> } catch (IOException e) {
>   // TODO: Revist Means that if a server is loaded, then we will 
> abort our host!
>   // In tests we abort the Master!
>   String msg = String.format("FAILED persisting region=%s state=%s",
> regionInfo.getShortNameToLog(), state);
>   LOG.error(msg, e);
>   master.abort(msg, e);
>   throw e;
> }
>   }
> {code}
> When regionserver (carry meta) stop or crash, if the ServerCrashProcedure 
> have not start process, write to meta will fail and abort master.   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [ANNOUNCE] New HBase committer Geoffrey Jacoby

[Esteban Gutierrez]

Congrats and welcome, Geoffrey!

--
Cloudera, Inc.



On Tue, Apr 13, 2021 at 8:18 AM zheng wang <18031...@qq.com> wrote:

> Congratulations!
>
>
>
>
> --原始邮件--
> 发件人:
>   "user"
> <
> vjas...@apache.org;
> 发送时间:2021年4月9日(星期五) 晚上7:53
> 收件人:"hbase-dev" u...@hbase.apache.org;
>
> 主题:[ANNOUNCE] New HBase committer Geoffrey Jacoby
>
>
>
> On behalf of the Apache HBase PMC I am pleased to announce that Geoffrey
> Jacoby has accepted the PMC's invitation to become a committer on the
> project.
>
> Thanks so much for the work you've been contributing. We look forward to
> your continued involvement.
>
> Congratulations and welcome, Geoffrey!

Re: [ANNOUNCE] New HBase PMC Huaxiang Sun

[Esteban Gutierrez]

Congratulations Huaxiang!


--
Cloudera, Inc.



On Tue, Apr 13, 2021 at 8:16 AM zheng wang <18031...@qq.com> wrote:

> Congratulations!
>
>
>
>
> --原始邮件--
> 发件人:
>   "user"
> <
> vjas...@apache.org;
> 发送时间:2021年4月13日(星期二) 下午4:09
> 收件人:"hbase-dev" u...@hbase.apache.org;
>
> 主题:[ANNOUNCE] New HBase PMC Huaxiang Sun
>
>
>
> On behalf of the Apache HBase PMC I am pleased to announce that Huaxiang
> Sun has accepted our invitation to become a PMC member on the HBase
> project. We appreciate Huaxiang stepping up to take more responsibility for
> the project.
>
> Congratulations and welcome, Huaxiang!

Re: [ANNOUNCE] New HBase committer Xin Sun

[Esteban Gutierrez]

Congrats, Xin!


--
Cloudera, Inc.



On Fri, Dec 4, 2020 at 11:48 AM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations and welcome!
>
> From: Guanghao Zhang 
> Reply-To: "u...@hbase.apache.org" 
> Date: Thursday, December 3, 2020 at 10:13 AM
> To: HBase Dev List , Hbase-User <
> u...@hbase.apache.org>
> Subject: [ANNOUNCE] New HBase committer Xin Sun
>
> Folks,
>
> On behalf of the Apache HBase PMC I am pleased to announce that Xin Sun has
> accepted the PMC's invitation to become a committer on the project.
>
> We appreciate all of the great contributions Xin Sun has made to the
> community thus far and we look forward to his continued involvement.
>
> Allow me to be the first to congratulate Xin Sun on his new role!
>
> Thanks.
>
>

Re: [ANNOUNCE] New HBase committer Yulin Niu

[Esteban Gutierrez]

Congratulations, Yulin!

--
Cloudera, Inc.



On Fri, Dec 4, 2020 at 11:49 AM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations and welcome!
>
> From: Guanghao Zhang 
> Reply-To: "dev@hbase.apache.org" 
> Date: Thursday, December 3, 2020 at 10:11 AM
> To: HBase Dev List , Hbase-User <
> u...@hbase.apache.org>
> Subject: [ANNOUNCE] New HBase committer Yulin Niu
>
> Folks,
>
> On behalf of the Apache HBase PMC I am pleased to announce that Yulin Niu
> has accepted the PMC's invitation to become a committer on the project.
>
> We appreciate all of the great contributions Yulin has made to the
> community thus far and we look forward to his continued involvement.
>
> Allow me to be the first to congratulate Yulin on his new role!
>
> Thanks.
>
>

Re: [ANNOUNCE] New HBase Committer Zheng Wang(王正)

[Esteban Gutierrez]

Congratulations Zheng!

esteban.

--
Cloudera, Inc.



On Mon, Sep 28, 2020 at 6:37 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:

> Congratulations Zheng Wang! Welcome!
>
> Em dom., 27 de set. de 2020 às 17:42, Andrew Purtell <
> andrew.purt...@gmail.com> escreveu:
>
> > Congratulations and welcome!
> >
> > > On Sep 23, 2020, at 7:25 PM, 张铎(Duo Zhang) 
> > wrote:
> > >
> > > On behalf of the Apache HBase PMC, I am pleased to announce that Zheng
> > Wang
> > > has accepted the PMC's invitation to become a committer on the project.
> > We
> > > appreciate all of Zheng's generous contributions thus far and look
> > forward
> > > to his continued involvement.
> > >
> > > Congratulations and welcome, Zheng Wang!
> > >
> > > 我很高兴代表Apache HBase PMC宣布王正已接受我们的邀请，成为Apache
> > > HBase项目的Committer。感谢王正一直以来为HBase项目做出的贡献，并期待他在未来继续承担更多的责任。
> > >
> > > 欢迎王正！
> >
>

[jira] [Resolved] (HBASE-19352) Port HADOOP-10379: Protect authentication cookies with the HttpOnly and Secure flags

[Esteban Gutierrez (Jira)]

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

Esteban Gutierrez resolved HBASE-19352.
---
Fix Version/s: 2.2.6
   2.4.0
   2.3.3
   3.0.0-alpha-1
 Tags: security
   Resolution: Fixed

> Port HADOOP-10379: Protect authentication cookies with the HttpOnly and 
> Secure flags
> 
>
> Key: HBASE-19352
> URL: https://issues.apache.org/jira/browse/HBASE-19352
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>    Reporter: Esteban Gutierrez
>    Assignee: Esteban Gutierrez
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.3.3, 2.4.0, 2.2.6
>
> Attachments: HBASE-19352.master.v0.patch
>
>
> This came via a security scanner, since we have a fork of HttpServer2 in 
> HBase we should include it too.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Removing problematic terms from our project

[Esteban Gutierrez]

+1 to remove master-slave terminology and favor the proposals that Andrew
mentions. This is the right thing to do as community.

Thanks,
Esteban.
--
Cloudera, Inc.



On Mon, Jun 22, 2020 at 4:28 PM Zach York 
wrote:

> While reading the definitions, I think it is pretty clear that the
> definition HBase is intending is somewhere under the #2 definition link.
> HMaster is not a teacher (which implies learning on the "student" side),
> but rather orders the RS to do a task.
> I think master in this context is still worth changing to coordinator since
> in my mind this is actually a more clear definition of what HMaster does.
>
> On Mon, Jun 22, 2020 at 2:09 PM Geoffrey Jacoby 
> wrote:
>
> > For most of the proposals (slave -> worker, blacklist -> denylist,
> > whitelist-> allowlist), I'm +1 (nonbinding). Denylist and acceptlist even
> > have the advantage of being clearer than the terms they're replacing.
> >
> > However, I'm not convinced about changing "master" to "coordinator", or
> > something similar. Unlike "slave", which is negative in any context,
> > "master" has many definitions, including some common ones which do not
> > appear problematic. See
> https://www.merriam-webster.com/dictionary/master
> > for
> > examples. In particular, the progression of an artisan was from
> > "apprentice" to "journeyman" to "master". A master smith, carpenter, or
> > artist would run a shop managing lots of workers and apprentices who
> would
> > hope to become masters of their own someday. So "master" and "worker" can
> > still go together.
> >
> > Since it's the least problematic term, and by far the hardest term to
> > change (both within HBase and with effects on downstream projects such as
> > Ambari), I'm -0 (nonbinding) on changing "master".
> >
> > Geoffrey
> >
> > On Mon, Jun 22, 2020 at 1:32 PM Rushabh Shah
> >  wrote:
> >
> > > +1 to renaming.
> > >
> > >
> > > Rushabh Shah
> > >
> > >- Software Engineering SMTS | Salesforce
> > >-
> > >   - Mobile: 213 422 9052
> > >
> > >
> > >
> > > On Mon, Jun 22, 2020 at 1:18 PM Josh Elser  wrote:
> > >
> > > > +1
> > > >
> > > > On 6/22/20 4:03 PM, Sean Busbey wrote:
> > > > > We should change our use of these terms. We can be equally or more
> > > clear
> > > > in
> > > > > what we are trying to convey where they are present.
> > > > >
> > > > > That they have been used historically is only useful if the
> advantage
> > > we
> > > > > gain from using them through that shared context outweighs the
> > > potential
> > > > > friction they add. They make me personally less enthusiastic about
> > > > > contributing. That's enough friction for me to advocate removing
> > them.
> > > > >
> > > > > AFAICT reworking our replication stuff in terms of "active" and
> > > "passive"
> > > > > clusters did not result in a big spike of folks asking new
> questions
> > > > about
> > > > > where authority for state was.
> > > > >
> > > > > On Mon, Jun 22, 2020, 13:39 Andrew Purtell 
> > > wrote:
> > > > >
> > > > >> In response to renewed attention at the Foundation toward
> addressing
> > > > >> culturally problematic language and terms often used in technical
> > > > >> documentation and discussion, several projects have begun
> > discussions,
> > > > or
> > > > >> made proposals, or started work along these lines.
> > > > >>
> > > > >> The HBase PMC began its own discussion on private@ on June 9,
> 2020
> > > > with an
> > > > >> observation of this activity and this suggestion:
> > > > >>
> > > > >> There is a renewed push back against classic technology industry
> > terms
> > > > that
> > > > >> have negative modern connotations.
> > > > >>
> > > > >> In the case of HBase, the following substitutions might be
> proposed:
> > > > >>
> > > > >> - Coordinator instead of master
> > > > >>
> > > > >> - Worker instead of slave
> > > > >>
> > > > >> Recommendations for these additional substitutions also come up in
> > > this
> > > > >> type of discussion:
> > > > >>
> > > > >> - Accept list instead of white list
> > > > >>
> > > > >> - Deny list instead of black list
> > > > >>
> > > > >> Unfortunately we have Master all over our code base, baked into
> > > various
> > > > >> APIs and configuration variable names, so for us the necessary
> > changes
> > > > >> amount to a new major release and deprecation cycle. It could well
> > be
> > > > worth
> > > > >> it in the long run. We exist only as long as we draw a willing and
> > > > >> sufficient contributor community. It also wouldn’t be great to
> have
> > an
> > > > >> activist fork appear somewhere, even if unlikely to be successful.
> > > > >>
> > > > >> Relevant JIRAs are:
> > > > >>
> > > > >> - HBASE-12677 <
> > https://issues.apache.org/jira/browse/HBASE-12677
> > > >:
> > > > >> Update replication docs to clarify terminology
> > > > >> - HBASE-13852 <
> > https://issues.apache.org/jira/browse/HBASE-13852
> > > >:
> > > > >> Replace master-slave terminology in book, site, and javadoc
> > with a

Re: [ANNOUNCE] New HBase committer Wei-Chiu Chuang

[Esteban Gutierrez]

Congratulations Wei-Chiu! and welcome aboard!

Esteban.

--
Cloudera, Inc.



On Wed, May 13, 2020 at 4:11 PM Nick Dimiduk  wrote:

> Thank you Wei-Chiu for your contributions! Looking forward to continuing to
> work together :)
>
> On Wed, May 13, 2020 at 2:01 PM Rushabh Shah
>  wrote:
>
> > Congratulations Wei-Chiu !!
> >
> >
> > Rushabh Shah
> >
> >- Software Engineering SMTS | Salesforce
> >-
> >   - Mobile: 213 422 9052
> >
> >
> >
> > On Wed, May 13, 2020 at 1:35 PM Zach York 
> > wrote:
> >
> > > Congratulations Wei-Chiu!
> > >
> > > On Wed, May 13, 2020 at 12:15 PM Bharath Vissapragada <
> > bhara...@apache.org
> > > >
> > > wrote:
> > >
> > > > Congrats, Wei-Chiu.
> > > >
> > > > On Wed, May 13, 2020 at 12:13 PM Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > Congratulations and welcome Wei-Chiu!
> > > > >
> > > > > On Wed, May 13, 2020 at 12:10 PM Sean Busbey 
> > > wrote:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > On behalf of the Apache HBase PMC I am pleased to announce that
> > > > Wei-Chiu
> > > > > > Chuang has accepted the PMC's invitation to become a committer on
> > the
> > > > > > project.
> > > > > >
> > > > > > We appreciate all of the great contributions Wei-Chiu has made to
> > the
> > > > > > community thus far and we look forward to his continued
> > involvement.
> > > > > >
> > > > > > Allow me to be the first to congratulate Wei-Chiu on his new
> role!
> > > > > >
> > > > > > thanks,
> > > > > > busbey
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > Words like orphans lost among the crosstalk, meaning torn from
> > truth's
> > > > > decrepit hands
> > > > >- A23, Crosstalk
> > > > >
> > > >
> > >
> >
>

Re: DISCUSS: Move hbase-thrift and hbase-rest out of core to hbase-connectors project?

[Esteban Gutierrez]

+1

But it would be great if we can deprecate their presence of those modules
first in 2.3

thanks,
esteban.

--
Cloudera, Inc.



On Mon, Apr 27, 2020 at 11:44 AM Josh Elser  wrote:

> +1 to the idea, -0 to the implied execution
>
> I agree hbase-connectors is a better place for REST and thrift, long term.
>
> My concern is that I read this thread as suggesting:
>
> 1. Remove rest/thrift from 2.3
> 1a. Proceed with 2.3.0 rc's
> 2. Add rest/thrift to hbase-connectors
> ...
> n. Release hbase-connectors
>
> I'm not a fan of removing anything which was previously there until
> there is are new releases and documentation to tell me how to do it. I'm
> still trying to help dig out another project who did the 'remove and
> then migrate" and left a pile of busted.
>
> If that's not what you were suggesting, let me shirk back into the
> shadows ;)
>
> On 4/25/20 7:44 PM, Stack wrote:
> > On Fri, Apr 24, 2020 at 10:06 PM Sean Busbey  wrote:
> >
> >> By "works with it" do you mean has documented steps to work with it or
> do
> >> you mean that the convenience binary that ships for 2.3.0 will have the
> >> same deployment model as prior 2.y releases where I can run those
> services
> >> directly from the download?
> >>
> >>
> > Former. Not the latter. They would no-longer be part of the hbase-2.3.x
> > distribution.
> > S
> >
> >
> >
> >
>

Re: [DISCUSS] Arrange Events for 10-year Anniversary

[Esteban Gutierrez]

Yeah, the TLP announcement date is good for that.

thanks,
esteban.


--
Cloudera, Inc.



On Wed, Apr 15, 2020 at 12:07 PM Sean Busbey  wrote:

> That was probably when our community was still covered under the
> Hadoop project. Essentially our version of being in the incubator.
>
> This is when we became our own TLP:
>
> https://whimsy.apache.org/board/minutes/HBase.html#2010-04-21
>
> On Wed, Apr 15, 2020 at 11:25 AM Vladimir Rodionov
>  wrote:
> >
> > 2020 - 10 = 2010. As far as I remember I joined HBase community in 2009
> :)
> > and I am pretty sure that Mr. Stack did it even earlier.
> >
> > Best regards,
> > Vlad
> >
> > On Wed, Apr 15, 2020 at 5:57 AM Yu Li  wrote:
> >
> > > Dear all,
> > >
> > > Since our project has reached its 10th birthday, and 10 years is
> definitely
> > > a great milestone, I propose to arrange some special (virtual) events
> for
> > > celebration. What comes into my mind include:
> > >
> > > * Open threads to collect voices from our dev/user mailing list, like
> "what
> > > do you want to say to HBase for its 10th birthday" (as well as our
> twitter
> > > accounts maybe, if any)
> > >
> > > * Arrange some online interviews to both PMC members and our customers.
> > > Some of us have been in this project all the way and there must be some
> > > good stories to tell, as well as expectations for the future.
> > >
> > > * Join the Apache Feathercast as suggested in another thread.
> > >
> > > * Form a blogpost to include all above events as an official
> celebration.
> > >
> > > What do you think? Any other good ideas? Looking forward to more voices
> > > (smile).
> > >
> > > Best Regards,
> > > Yu
> > >
>

[jira] [Resolved] (HBASE-24041) [regression] Increase RESTServer buffer size back to 64k

[Esteban Gutierrez (Jira)]

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

Esteban Gutierrez resolved HBASE-24041.
---
Fix Version/s: 2.2.5
   2.4.0
   2.3.0
   3.0.0
   Resolution: Fixed

> [regression]  Increase RESTServer buffer size back to 64k
> -
>
> Key: HBASE-24041
> URL: https://issues.apache.org/jira/browse/HBASE-24041
> Project: HBase
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 3.0.0, 2.2.0, 2.3.0, 2.4.0
>    Reporter: Esteban Gutierrez
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.4.0, 2.2.5
>
>
> HBASE-14492 is not longer present in our current releases after HBASE-12894. 
> Unfortunately our RESTServer is not extending HttpServer which means that 
> {{DEFAULT_MAX_HEADER_SIZE}} is not being set and HTTP requests with a very 
> large header can still cause connection issues for clients. A quick fix is 
> just to add the settings to the {{HttpConfiguration}} configuration object. A 
> long term solution should be to re-factor services that create an HTTP server 
> and normalize all configuration settings across all of them.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (HBASE-24041) [regression] Increase RESTServer buffer size back to 64k

[Esteban Gutierrez (Jira)]

Esteban Gutierrez created HBASE-24041:
-

 Summary: [regression]  Increase RESTServer buffer size back to 64k
 Key: HBASE-24041
 URL: https://issues.apache.org/jira/browse/HBASE-24041
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.2.0, 3.0.0, 2.3.0, 2.4.0
Reporter: Esteban Gutierrez


HBASE-14492 is not longer present in our current releases after HBASE-12894. 
Unfortunately our RESTServer is not extending HttpServer which means that 
{{DEFAULT_MAX_HEADER_SIZE}} is not being set and HTTP requests with a very 
large header can still cause connection issues for clients. A quick fix is just 
to add the settings to the {{HttpConfiguration}} configuration object. A long 
term solution should be to re-factor services that create an HTTP server and 
normalize all configuration settings across all of them.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [ANNOUNCE] New HBase committer Bharath Vissapragada

[Esteban Gutierrez]

Yay! Congratulations Bharath!

esteban.
--
Cloudera, Inc.



On Thu, Feb 6, 2020 at 12:07 PM Andrew Purtell  wrote:

> Congratulations and welcome, Bharath!
>
> On Wed, Feb 5, 2020 at 7:36 PM Nick Dimiduk  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Bharath
> > Vissapragada has accepted the PMC's invitation to become a commiter on
> the
> > project. We appreciate all of Bharath's generous contributions thus far
> and
> > look forward to his continued involvement.
> >
> > Allow me to be the first to congratulate and welcome Bharath into his new
> > role!
> >
> > Thanks,
> > Nick
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] Please welcome Guangxu Cheng the HBase PMC

[Esteban Gutierrez]

Congrats Guangxu!
--
Cloudera, Inc.



On Mon, Dec 9, 2019 at 12:03 PM Karthik Palanisamy 
wrote:

> Superb!! Congratulations Guangxu Cheng!!!
>
> On Mon, Dec 9, 2019 at 5:58 AM Jan Hentschel <
> jan.hentsc...@ultratendency.com> wrote:
>
> > Congratulations and welcome!
> >
> > From: Duo Zhang 
> > Reply-To: "dev@hbase.apache.org" 
> > Date: Monday, December 9, 2019 at 10:47 AM
> > To: HBase Dev List , hbase-user <
> > u...@hbase.apache.org>
> > Subject: [ANNOUNCE] Please welcome Guangxu Cheng the HBase PMC
> >
> > On behalf of the Apache HBase PMC I am pleased to announce that Guangxu
> > Cheng has accepted our invitation to become a PMC member on the Apache
> > HBase project. We appreciate Guangxu Cheng stepping up to take more
> > responsibility in the HBase project.
> >
> > Please join me in welcoming Guangxu Cheng to the HBase PMC!
> >
> >
>

Re: [ANNOUNCE] New HBase committer Ankit Singhal

[Esteban Gutierrez]

Congrats, Ankit!
--
Cloudera, Inc.



On Tue, Nov 12, 2019 at 2:59 PM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations and welcome!
>
> From: Josh Elser 
> Reply-To: "dev@hbase.apache.org" 
> Date: Tuesday, November 12, 2019 at 5:39 PM
> To: dev 
> Subject: [ANNOUNCE] New HBase committer Ankit Singhal
>
> On behalf of the Apache HBase PMC, I'm pleased to announce that Ankit
> Singhal has accepted our invitation to become an HBase committer.
>
> Thanks for all of your contributions to the HBase project and we look
> forward to your continued growth and participation.
>
> Congratulations!
>
>

Re: [ANNOUNCE] Please welcome Balazs Meszaros to the Apache HBase PMC

[Esteban Gutierrez]

Congrats, Balazs!

esteban.
--
Cloudera, Inc.



On Thu, Oct 24, 2019 at 11:05 AM Sakthi  wrote:

> Congrats Balazs! Well done.
>
> On Thu, Oct 24, 2019 at 7:52 AM Guangxu Cheng 
> wrote:
>
> > Congratulations, Balazs!
> >
> > Wellington Chevreuil  于2019年10月24日周四
> > 下午10:47写道：
> >
> > > Congratulations, Balazs!
> > >
> > > Em qui, 24 de out de 2019 às 15:34, Sean Busbey 
> > > escreveu:
> > >
> > > > On behalf of the Apache HBase PMC I am pleased to announce that
> > > > Balazs Meszaros has accepted our invitation to become a PMC member on
> > the
> > > > HBase project. We appreciate Balazs stepping up to take more
> > > > responsibility in the HBase project.
> > > >
> > > > Please join me in welcoming Balazs to the HBase PMC!
> > > >
> > > >
> > > >
> > > > As a reminder, if anyone would like to nominate another person as a
> > > > committer or PMC member, even if you are not currently a committer or
> > > > PMC member, you can always drop a note to priv...@hbase.apache.org
> to
> > > > let us know.
> > > >
> > >
> >
>

Re: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache HBase PMC

[Esteban Gutierrez]

Congratulations,  Wellington! nicely done!

thanks,
esteban.

--
Cloudera, Inc.



On Fri, Oct 25, 2019 at 8:06 AM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations! Well deserved.
>
> Best, Jan
>
> From: Sean Busbey 
> Reply-To: "dev@hbase.apache.org" 
> Date: Wednesday, October 23, 2019 at 10:16 PM
> To: dev , Hbase-User 
> Subject: [ANNOUNCE] Please welcome Wellington Chevreuil to the Apache
> HBase PMC
>
> On behalf of the Apache HBase PMC I am pleased to announce that
> Wellington Chevreuil has accepted our invitation to become a PMC member on
> the
> HBase project. We appreciate Wellington stepping up to take more
> responsibility in the HBase project.
>
> Please join me in welcoming Wellington to the HBase PMC!
>
>
>
> As a reminder, if anyone would like to nominate another person as a
> committer or PMC member, even if you are not currently a committer or
> PMC member, you can always drop a note to priv...@hbase.apache.org priv...@hbase.apache.org> to
> let us know.
>
>

Re: [ANNOUNCE] Please welcome Sakthi to the Apache HBase PMC

[Esteban Gutierrez]

Congratulations, Sakthi!

--
Cloudera, Inc.



On Fri, Oct 25, 2019 at 7:57 AM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations! Well deserved.
>
> Best, Jan
>
> From: Sean Busbey 
> Reply-To: "dev@hbase.apache.org" 
> Date: Wednesday, October 23, 2019 at 10:15 PM
> To: dev , Hbase-User 
> Subject: Re: [ANNOUNCE] Please welcome Sakthi to the Apache HBase PMC
>
> Please join me in welcoming Sakthi to the HBase PMC, of course.
>
> Welcome Sakthi! Well deserved!
>
> On Wed, Oct 23, 2019 at 3:14 PM Sean Busbey  bus...@apache.org>> wrote:
>
> On behalf of the Apache HBase PMC I am pleased to announce that
> Sakthi has accepted our invitation to become a PMC member on the
> HBase project. We appreciate Sakthi stepping up to take more
> responsibility in the HBase project.
>
> Please join me in welcoming Jan to the HBase PMC!
>
>
>
> As a reminder, if anyone would like to nominate another person as a
> committer or PMC member, even if you are not currently a committer or
> PMC member, you can always drop a note to priv...@hbase.apache.org priv...@hbase.apache.org> to
> let us know.
>
>

Re: [VOTE] The second HBase Operator Tools 1.0.0 release candidate (RC1) is available

[Esteban Gutierrez]

+1

built from source: +1
signatures: +1
sha512 checksum: +1
unit tests passed: +1
ran some commands: +1

Thanks!
esteban.
--
Cloudera, Inc.



On Fri, Sep 20, 2019 at 8:49 PM Guanghao Zhang  wrote:

> +1
>
> Built from source: ok (openjdk 1.8.0_202)
> Signatures and checksum: ok
> CHANGES and RELEASENOTES: ok
>
> Stack  于2019年9月21日周六 上午8:32写道：
>
> > +1
> >
> > Signatures and hash are good.
> > CHANGES and RELEASENOTES look complete.
> > Built from src and ran a few commands.
> >
> > S
> >
> >
> >
> > On Fri, Sep 20, 2019 at 8:34 AM Peter Somogyi 
> wrote:
> >
> > > Please vote on this Apache HBase Operator Tools Release Candidate (RC),
> > > 1.0.0.
> > >
> > > The VOTE will remain open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache HBase Operator Tools 1.0.0
> > > [ ] -1 Do not release this package because ...
> > >
> > > The tag to be voted on is 1.0.0RC1:
> > >
> > >  https://github.com/apache/hbase-operator-tools/tree/1.0.0RC1
> > >
> > > The release files, including signatures, digests, as well as CHANGES.md
> > > and RELEASENOTES.md included in this RC can be found at:
> > >
> > >  https://dist.apache.org/repos/dist/dev/hbase/1.0.0RC1/
> > >
> > > Maven artifacts are available in a staging repository at:
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1349/
> > >
> > > Artifacts were signed with the psomo...@apache.org key which can be
> > found
> > > in:
> > >
> > >  https://dist.apache.org/repos/dist/release/hbase/KEYS
> > >
> > > To learn more about Apache HBase Operator Tools, please see
> > > http://hbase.apache.org/
> > >
> > > Thanks,
> > > Your HBase Release Manager
> > >
> >
>

[jira] [Created] (HBASE-22926) REST server should return 504 Gateway Timeout Error on scanner timeout

[Esteban Gutierrez (Jira)]

Esteban Gutierrez created HBASE-22926:
-

 Summary: REST server should return 504 Gateway Timeout Error on 
scanner timeout
 Key: HBASE-22926
 URL: https://issues.apache.org/jira/browse/HBASE-22926
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 2.2.0, 2.1.0, 3.0.0
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


Currently when a scanner timeout error occurs on the RS side, a client will get 
a RetriesExhaustedException that will make the client to fail, however from the 
REST server point of view that is just an IOE:

org.apache.hadoop.hbase.rest.ScannerResultGenerator#next
{code}
} else {
Result result = null;
try {
  result = scanner.next();
} catch (UnknownScannerException e) {
  throw new IllegalArgumentException(e);
} catch (TableNotEnabledException tnee) {
  throw new IllegalStateException(tnee);
} catch (TableNotFoundException tnfe) {
  throw new IllegalArgumentException(tnfe);
} catch (IOException e) {
  LOG.error(StringUtils.stringifyException(e));
}
{code}

Now, with that empty result (will handle this as an HTTP 204 response back to 
the client:

org.apache.hadoop.hbase.rest.ScannerInstanceResource#get
{code}
...
  Cell value = null;
  try {
value = generator.next();
  } catch (IllegalStateException e) {
...
  } catch (IllegalArgumentException e) {
...
  }
...
if (value == null) {
if (LOG.isTraceEnabled()) {
  LOG.trace("generator exhausted");
}
// respond with 204 (No Content) if an empty cell set would be
// returned
if (count == limit) {
  return Response.noContent().build();
}
break;
{code}

Obviously this is wrong, since a RetriesExhaustedException is most likely due a 
failure in the RS side. The correct behavior should be a 504 Gateway Timeout 
Error.






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [NOTICE] Reid Chan has been added to the HBASE PMC!

[Esteban Gutierrez]

Congrats, Reid!

--
Cloudera, Inc.



On Fri, Aug 16, 2019 at 1:36 PM Andrew Purtell  wrote:

> Congratulations, Reid!
>
>
> On Fri, Aug 16, 2019 at 10:30 AM Stack  wrote:
>
> > The mighty Reid Chan has been added to the hbase PMC. A bunch of us
> thought
> > he was on the PMC already but on a whim, I took a look and noticed that
> he
> > wasn't. Reid Chan has been a healthy influence about the place especially
> > contributing helping new contributors getting acclimatized to the ways
> and
> > means of hbase contribution helping keep up standards. He's a fabulous
> > resource to have about the project. Letting you all know he's been added
> to
> > the PMC.
> > Yours,
> > S
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] Please welcome Zheng Hu to the HBase PMC

[Esteban Gutierrez]

Congrats Zheng!

Thanks,
Esteban.

--
Cloudera, Inc.



On Tue, Aug 6, 2019 at 8:13 AM Sean Busbey  wrote:

> Thanks for taking on these added responsibilities Zheng!
>
> On Sun, Aug 4, 2019 at 9:08 PM Duo Zhang  wrote:
> >
> > On behalf of the Apache HBase PMC I am pleased to announce that Zheng Hu
> > has accepted our invitation to become a PMC member on the Apache HBase
> > project. We appreciate Zheng Hu stepping up to take more responsibility
> in
> > the HBase project.
> >
> > Please join me in welcoming Zheng Hu to the HBase PMC!
>

Re: [ANNOUNCE] New HBase committer Tak-Lon (Stephen) Wu

[Esteban Gutierrez]

Woot! Congrats Stephen! and welcome!

--
Cloudera, Inc.



On Mon, Aug 5, 2019 at 2:04 PM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:

> Congratulations and welcome!
> From: Sean Busbey 
> Reply-To: "u...@hbase.apache.org" 
> Date: Monday, August 5, 2019 at 8:53 PM
> To: dev , "u...@hbase.apache.org" <
> u...@hbase.apache.org>
> Subject: [ANNOUNCE] New HBase committer Tak-Lon (Stephen) Wu
>
> On behalf of the Apache HBase PMC I am super pleased to announce that
> Tak-Lon (Stephen) Wu has accepted the PMC's invitation to become a
> commiter on the project.
>
> Thanks so much for the work you've been contributing. We look forward
> to your continued involvement.
>
> Congratulations and welcome!
>
> -busbey
>
>

Re: [VOTE] First HBase File FileSystem 1.0.0-alpha1-RC0

[Esteban Gutierrez]

+1

- Build from source: OK
- Tests run, 160: OK
- Checksums and signatures: OK
- RAT: OK


--
Cloudera, Inc.



On Mon, Jun 10, 2019 at 2:08 PM Andrew Purtell  wrote:

> +1
>
> Sums and signatures ok
> Built from source, ok
> RAT check passes
> Tests pass, Hadoop 2
> Tests pass, Hadoop 3
>
>
> On Fri, Jun 7, 2019 at 7:25 AM Wellington Chevreuil <
> wellington.chevre...@gmail.com> wrote:
>
> > Please vote on this first HBase FileSystem 1.0.0-alpha1 release
> candidate.
> >
> > The release files including signatures can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-filesystem-1.0.0-alpha1-RC0/
> >
> > Maven artifacts are available here:
> > https://repository.apache.org/content/repositories/orgapachehbase-1321/
> >
> > Artifacts were signed with wellington.chevre...@gmail.com key available
> > at:
> > https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > Compatibility information:
> > - hadoop 2.9.2
> > - hadoop 3.2.0
> > - hbase 2.1.4
> >
> > As the first alpha release for hbase-filesystem project, it only includes
> > hbase-oss module, which includes implementation of Hadoop FileSystem
> > interface semantics for Object Stores. Further implementation and
> > configuration details are available on hbase-oss/README.md file.
> >
> > Please try out the candidate and vote +1/0/-1.
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New Committer: Wellington Chevreuil

[Esteban Gutierrez]

Congratulations, Wellington!


On Fri, Jun 7, 2019 at 07:22 Toshihiro Suzuki  wrote:

> Congratulations Wellington!
>
> On Fri, Jun 7, 2019 at 9:10 PM Artem Ervits  wrote:
>
> > congras Wellington!
> >
> > On Fri, Jun 7, 2019 at 8:00 AM ramkrishna vasudevan <
> > ramkrishna.s.vasude...@gmail.com> wrote:
> >
> > > Congratulations Wellington !!
> > >
> > > Regards
> > > Ram
> > >
> > > On Fri, Jun 7, 2019 at 5:28 PM Sean Busbey  wrote:
> > >
> > > > congrats Wellington!
> > > >
> > > > On 2019/06/07 10:11:48, Peter Somogyi  wrote:
> > > > > On behalf of the HBase PMC, I'm pleased to announce that Wellington
> > > > > Chevreuil has accepted our invitation to become an HBase committer.
> > > > >
> > > > > Thanks for all your hard work Wellington; we look forward to more
> > > > > contributions!
> > > > >
> > > > > Please join me in extending congratulations to Wellington!
> > > > >
> > > >
> > >
> >
>
-- 
--
Cloudera, Inc.

Re: Does HBase master process need to do listSnapshots

[Esteban Gutierrez]

Hello Abhishek,

The HBase master UI will try to list the snapshots if there are available.
Since GetCompletedSnapshots goes to the filesystem to scan for all the
possible snapshots that can take some time depending on the number of
snapshots or the load of the NN.

thanks,
esteban.


--
Cloudera, Inc.



On Thu, May 30, 2019 at 12:05 PM Abhishek Gupta  wrote:

> Hi,
>
> We are trying to debug an issue where multiple listSnapshots calls seem to
> be running extremely slow RPC calls on HBase Master.
> These calls appear to be happening from Master node itself. I wanted to
> understand if there is any Master chore service that needs to periodically
> do an operation which involves a lisSnapshots?
>
> *{"call":"GetCompletedSnapshots(org.apache.hadoop.hbase.protobuf.generated.MasterProtos$GetCompletedSnapshotsRequest)","starttimems":1559233674685,"responsesize":175421,"method":"GetCompletedSnapshots","processingtimems":420615,"client":"
> 10.0.1.193:58296
> ","queuetimems":0,"class":"HMaster"}*
> Some of these calls are taking 1000 seconds of processing time.
>
> Thanks in advance,
> Abhishek
>

Re: [ANNOUNCE] New HBase committer Yi Mei

[Esteban Gutierrez]

Congratulations, Yi Mei!

--
Cloudera, Inc.



On Fri, May 24, 2019 at 2:12 AM Guanghao Zhang  wrote:

> On behalf of the Apache HBase PMC, I am pleased to announce that Yi Mei has
> accepted the PMC's invitation to become a committer on the project. We
> appreciate all of Yi Mei's generous contributions thus far and look forward
> to Yi Mei's continued involvement.
>
> Congratulations and welcome, Yi Mei!
>

Re: [ANNOUNCE] Please welcome Jan Hentschel to the Apache HBase PMC

[Esteban Gutierrez]

Congrats, Jan!

--
Cloudera, Inc.



On Sun, May 12, 2019 at 8:34 PM Guanghao Zhang  wrote:

> Congratulations
>
> Jan Hentschel  于2019年5月13日周一 上午3:19写道：
>
> > Thanks everybody. It’s an honor and I’ll try to do my best to help the
> > project and the community.
> >
> > From: Balazs Meszaros 
> > Reply-To: "dev@hbase.apache.org" 
> > Date: Thursday, May 9, 2019 at 1:19 PM
> > To: "dev@hbase.apache.org" 
> > Cc: "u...@hbase.apache.org" 
> > Subject: Re: [ANNOUNCE] Please welcome Jan Hentschel to the Apache HBase
> > PMC
> >
> > Congratulations Jan!
> >
> > On Thu, May 9, 2019 at 12:07 PM Lars Francke  > > wrote:
> >
> > Congratulations Jan and especially thank you for your work on the
> > deprecations
> >
> > On Wed, May 8, 2019 at 11:37 PM Sean Busbey  > bus...@apache.org>> wrote:
> >
> > > On behalf of the Apache HBase PMC I am pleased to announce that Jan
> > > Hentschel has accepted our invitation to become a PMC member on the
> > > HBase project. We appreciate Jan stepping up to take more
> > > responsibility in the HBase project.
> > >
> > > Please join me in welcoming Jan to the HBase PMC!
> > >
> > >
> > >
> > > As a reminder, if anyone would like to nominate another person as a
> > > committer or PMC member, even if you are not currently a committer or
> > > PMC member, you can always drop a note to priv...@hbase.apache.org
> >  to
> > > let us know.
> > >
> > > -busbey
> > >
> >
> >
> >
>

[jira] [Created] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-22253:
-

 Summary: An AuthenticationTokenSecretManager leader won't step 
down if another RS claims to be a leader
 Key: HBASE-22253
 URL: https://issues.apache.org/jira/browse/HBASE-22253
 Project: HBase
  Issue Type: Bug
  Components: security
Affects Versions: 2.1.0, 3.0.0, 2.2.0
Reporter: Esteban Gutierrez


We ran into a situation were a rouge Lily HBase Indexer [SEP 
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
 sharing the same {{zookeeper.znode.parent}} claimed to be 
AuthenticationTokenSecretManager for an HBase cluster. This situation 
undesirable since the leader running on the HBase cluster doesn't steps down 
when the rouge leader registers in the HBase cluster and both will start 
rolling keys with the same IDs causing authentication errors. Even a reasonable 
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make 
sure that we step down as leader correctly.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22019) Ability to remotely connect to hbase when hbase/zook is hosted on dynamic IP addresses

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-22019.
---
Resolution: Invalid

Thanks for reporting this, [~toopt4]. Please reach out the HBase user [mailing 
list|https://hbase.apache.org/mailing-lists.html] for this type of this 
problems since many users have been able to connect to HBase clusters without 
any problem regardless if the HBase is on different networks. 

> Ability to remotely connect to hbase when hbase/zook is hosted on dynamic IP 
> addresses
> --
>
> Key: HBASE-22019
> URL: https://issues.apache.org/jira/browse/HBASE-22019
> Project: HBase
>  Issue Type: New Feature
>  Components: IPC/RPC, Zookeeper
>Reporter: t oo
>Priority: Major
>
> Our team's need for this is purely for remote connections (ie personal 
> laptops) to HBASE (hosted on EC2) to work as hbase connections under the 
> cover connect to zookeeper (also running on EC2) and attempt to resolve the 
> hostname (not DNS!) of the machine running zookeeper. From what I've read 
> others  re facing the issue:
> https://forums.aws.amazon.com/thread.jspa?threadID=119915
> https://stackoverflow.com/questions/30751187/unable-to-connect-to-hbase-stand-alone-server-from-windows-remote-client
> https://sematext.com/opensee/m/HBase/YGbbw6MGk1B9nCv?subj=Re:+Remote+Java+client+connection+into+EC2+instance
> https://community.cloudera.com/t5/Storage-Random-Access-HDFS/Problem-in-connectivity-between-HBase-amp-JAVA/td-p/1693
> https://stackoverflow.com/questions/9413481/hbase-node-could-not-be-reached-from-hbase-java-api-client
> https://groups.google.com/forum/#!topic/opentsdb/3w4FCnPYRDg
> Between ec2s I don't get the below error because I can edit /etc/hosts to add 
> the host name below but don't have root/admin access on other machines to do 
> the same. Problem is if we have 100s of users wanting to connect to hbase 
> data then they would all face this /etc/hosts issue.
> Example of the error:
> 19/03/01 17:02:14 WARN client.ConnectionUtils: Can not resolve 
> ip-10x.com, please check your network
> java.net.UnknownHostException: ip-10x.com: Name or service not known
>  at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
>  at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:929)
>  at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1324)
>  at java.net.InetAddress.getAllByName0(InetAddress.java:1277)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1193)
>  at java.net.InetAddress.getAllByName(InetAddress.java:1127)
>  at java.net.InetAddress.getByName(InetAddress.java:1077)
>  at 
> org.apache.hadoop.hbase.client.ConnectionUtils.getStubKey(ConnectionUtils.java:233)
>  at 
> org.apache.hadoop.hbase.client.ConnectionImplementation.getClient(ConnectionImplementation.java:1189)
>  at 
> org.apache.hadoop.hbase.client.ClientServiceCallable.setStubByServiceName(ClientServiceCallable.java:44)
>  at 
> org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:229)
>  at 
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:105)
>  at org.apache.hadoop.hbase.client.HTable.get(HTable.java:386)
>  at org.apache.hadoop.hbase.client.HTable.get(HTable.java:360)
>  at 
> org.apache.hadoop.hbase.MetaTableAccessor.getTableState(MetaTableAccessor.java:1066)
>  at 
> org.apache.hadoop.hbase.MetaTableAccessor.tableExists(MetaTableAccessor.java:389)
>  at org.apache.hadoop.hbase.client.HBaseAdmin$6.rpcCall(HBaseAdmin.java:437)
>  at org.apache.hadoop.hbase.client.HBaseAdmin$6.rpcCall(HBaseAdmin.java:434)
>  at 
> org.apache.hadoop.hbase.client.RpcRetryingCallable.call(RpcRetryingCallable.java:58)
>  at 
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:107)
>  at 
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:3055)
>  at 
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:3047)
>  at org.apache.hadoop.hbase.client.HBaseAdmin.tableExists(HBaseAdmin.java:434)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New HBase committer Xu Cang

[Esteban Gutierrez]

Congrats, Xu!

--
Cloudera, Inc.



On Sun, Feb 10, 2019 at 8:54 PM OpenInx  wrote:

> Congratulations!
>
> On Fri, Feb 8, 2019 at 7:42 PM 张铎(Duo Zhang) 
> wrote:
>
> > Congratulations!
> >
> > Allan Yang  于2019年2月8日周五 下午7:40写道：
> >
> > > Congratulations, Xu!
> > > Best Regards
> > > Allan Yang
> > >
> > >
> > > Xu Cang  于2019年2月7日周四 上午3:06写道：
> > >
> > > > Thank you all! Looking forward to contributing more and making more
> > > > meaningful impact on our community.
> > > >
> > > > Xu
> > > >
> > > > On Wed, Feb 6, 2019 at 1:13 AM Yuhao Bi  wrote:
> > > >
> > > > > Congratulations!
> > > > >
> > > > > Pankaj kr  于2019年2月6日周三 下午4:40写道：
> > > > >
> > > > > > Congratulations Xu...!!
> > > > > >
> > > > > > Regards,
> > > > > > Pankaj
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > > > > Sent: 06 February 2019 04:19
> > > > > > To: dev ; Hbase-User <
> u...@hbase.apache.org>
> > > > > > Subject: [ANNOUNCE] New HBase committer Xu Cang
> > > > > >
> > > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> Xu
> > > > Cang
> > > > > > has accepted the PMC's invitation to become a committer on the
> > > project.
> > > > > We
> > > > > > appreciate all of Xu's generous contributions thus far and look
> > > forward
> > > > > to
> > > > > > his continued involvement.
> > > > > >
> > > > > > Congratulations and welcome, Xu!
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Andrew
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [ANNOUNCE] Allan Yang joins the Apache HBase PMC

[Esteban Gutierrez]

Congratulations, Allan!

--
Cloudera, Inc.



On Wed, Nov 28, 2018 at 10:11 AM Yu Li  wrote:

> On behalf of the Apache HBase PMC I am pleased to announce that Allan Yang
> has accepted our invitation to become a PMC member on the Apache HBase
> project. We appreciate Allan stepping up to take more responsibility in the
> HBase project.
>
> Please join me in welcoming Allan to the HBase PMC!
>
> Best Regards,
> Yu
>

Re: [ANNOUNCE] Please welcome Zach York to the HBase PMC

[Esteban Gutierrez]

Congrats, Zach!

--
Cloudera, Inc.



On Thu, Oct 11, 2018 at 3:06 PM Ted Yu  wrote:

> Congratulations, Zach !
>
> On Thu, Oct 11, 2018 at 1:01 PM Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Zach
> > York has accepted our invitation to become a PMC member on the Apache
> > HBase project. We appreciate Zach stepping up to take more
> > responsibility in the HBase project.
> >
> > Please join me in welcoming Zach to the HBase PMC!
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or
> > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > let us know.
> >
>

Re: [ANNOUNCE] New Committer: Balazs Meszaros

[Esteban Gutierrez]

Congratulations and welcome, Balazs!

esteban.

--
Cloudera, Inc.



On Thu, Oct 11, 2018 at 2:57 PM Nihal Jain  wrote:

> Congrats Balazs :)
>
> On Fri 12 Oct, 2018, 1:20 AM Mike Drob,  wrote:
>
> > Welcome, Balazs!
> >
> > On Thu, Oct 11, 2018 at 2:49 PM Sean Busbey  wrote:
> >
> > > On behalf of the HBase PMC, I'm pleased to announce that Balazs
> > > Meszaros has accepted our invitation to become an HBase committer.
> > >
> > > Thanks for all your hard work Balazs; we look forward to more
> > > contributions!
> > >
> > > Please join me in extending congratulations to Balazs!
> > >
> >
>

[jira] [Created] (HBASE-21134) Add guardrails to cell tags in order to avoid the tags length to overflow

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-21134:
-

 Summary: Add guardrails to cell tags in order to avoid the tags 
length to overflow 
 Key: HBASE-21134
 URL: https://issues.apache.org/jira/browse/HBASE-21134
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Esteban Gutierrez


We found that per cell tags can easily overflow and and cause failures while 
reading HFiles. If a mutation has more than 32KB for the byte array with the 
tags we should reject the operation on the client side (proactively) and the 
server side as we deserialize the request.

{code}
2018-08-21 11:08:45,387 ERROR 
org.apache.hadoop.hbase.regionserver.CompactSplitThread: Compaction failed 
Request = regionName=table1,,1534870486680.9112ca53504084152da5e28116f40ec2., 
storeName=c1, fileCount=4, fileSize=254.2 K (138.0 K, 33.5 K, 34.0 K, 48.7 K), 
priority=1, time=8555785624243
java.lang.IllegalStateException: Invalid currTagsLen -20658. Block offset: 0, 
block length: 44912, position: 0 (without header).
at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV3$ScannerV3.checkTagsLen(HFileReaderV3.java:226)
at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV3$ScannerV3.readKeyValueLen(HFileReaderV3.java:251)
at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.updateCurrBlock(HFileReaderV2.java:956)
at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$ScannerV2.seekTo(HFileReaderV2.java:919)
at 
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekAtOrAfter(StoreFileScanner.java:304)
at 
org.apache.hadoop.hbase.regionserver.StoreFileScanner.seek(StoreFileScanner.java:200)
at 
org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:350)
at 
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:269)
at 
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:231)
at 
org.apache.hadoop.hbase.regionserver.compactions.Compactor.createScanner(Compactor.java:414)
at 
org.apache.hadoop.hbase.regionserver.compactions.DefaultCompactor.compact(DefaultCompactor.java:91)
at 
org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.compact(DefaultStoreEngine.java:125)
at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:1247)
at 
org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1915)
at 
org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.doCompaction(CompactSplitThread.java:529)
at 
org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.run(CompactSplitThread.java:566)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New Committer: Toshihiro Suzuki

[Esteban Gutierrez]

Congrats, Toshi! and welcome!

--
Cloudera, Inc.


On Wed, Aug 1, 2018 at 12:38 PM, Andrew Purtell  wrote:

> Congratulations! And welcome.
>
> On Wed, Aug 1, 2018 at 7:47 AM Josh Elser  wrote:
>
> > On behalf of the HBase PMC, I'm pleased to announce that Toshihiro
> > Suzuki (aka Toshi, brfn169) has accepted our invitation to become an
> > HBase committer. This was extended to Toshi as a result of his
> > consistent, high-quality contributions to HBase. Thanks for all of your
> > hard work, and we look forward to working with you even more!
> >
> > Please join me in extending a hearty "congrats" to Toshi!
> >
> > - Josh
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

[jira] [Created] (HBASE-20761) FSReaderImpl#readBlockDataInternal can fail to switch to HDFS checksums in some edge cases

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-20761:
-

 Summary: FSReaderImpl#readBlockDataInternal can fail to switch to 
HDFS checksums in some edge cases
 Key: HBASE-20761
 URL: https://issues.apache.org/jira/browse/HBASE-20761
 Project: HBase
  Issue Type: Bug
  Components: HFile
Reporter: Esteban Gutierrez


One of our users reported this problem on HBase 1.2 before and after 
HBASE-11625:

{code}
Caused by: java.io.IOException: On-disk size without header provided is 131131, 
but block header contains 0. Block offset: 2073954793, data starts with: 
\x00\x00\x00\x00\x00\x00\x00\x0\
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
at 
org.apache.hadoop.hbase.io.hfile.HFileBlock.validateOnDiskSizeWithoutHeader(HFileBlock.java:526)
at 
org.apache.hadoop.hbase.io.hfile.HFileBlock.access$700(HFileBlock.java:92)
at 
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockDataInternal(HFileBlock.java:1699)
at 
org.apache.hadoop.hbase.io.hfile.HFileBlock$FSReaderImpl.readBlockData(HFileBlock.java:1542)
at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:445)
at 
org.apache.hadoop.hbase.util.CompoundBloomFilter.contains(CompoundBloomFilter.java:100)
{code}

The problems occurs when we do a read a block without HDFS checksums enabled 
and due some data corruption we end with an empty headerBuf while trying to 
read the block before the HDFS checksum failover code. This will cause further 
attempts to read the block to fail since we will still retry the corrupt 
replica instead of reporting the corrupt replica and trying a different one. 








--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-20604) ProtobufLogReader#readNext can incorrectly loop to the same position in the stream until the the WAL is rolled

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-20604:
-

 Summary: ProtobufLogReader#readNext can incorrectly loop to the 
same position in the stream until the the WAL is rolled
 Key: HBASE-20604
 URL: https://issues.apache.org/jira/browse/HBASE-20604
 Project: HBase
  Issue Type: Bug
  Components: Replication, wal
Affects Versions: 3.0.0, 2.1.0, 1.5.0
Reporter: Esteban Gutierrez


Every time we call {{ProtobufLogReader#readNext}} we consume the input stream 
associated to the {{FSDataInputStream}} from the WAL that we are reading. Under 
certain conditions, e.g. when using the encryption at rest 
({{CryptoInputStream}}) the stream can return partial data which can cause a 
premature EOF that cause {{inputStream.getPos()}} to return to the same origina 
position causing {{ProtobufLogReader#readNext}} to re-try over the reads until 
the WAL is rolled.

The side effect of this issue is that {{ReplicationSource}} can get stuck until 
the WAL is rolled and causing replication delays up to an hour in some cases.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] The third release candidate for HBASE 2.0.0 (RC2) is available

[Esteban Gutierrez]

+1

signature: pass.
build: pass.
PE (randomWrite/randomRead): pass.
zkcli, wal, hfile, regionsplitter tools: pass.
started Thrift server: pass.
started REST server: pass.



--
Cloudera, Inc.


On Tue, Apr 24, 2018 at 3:13 AM, Balazs Meszaros <
balazs.mesza...@cloudera.com> wrote:

> +1
>
> - signatures and checksums: OK
> - rat check: OK
> - built from source (8u112): OK
> - basic shell functionalities: OK
> - web UI: OK
> - LTT with 1M rows: OK
>
>
> On Mon, Apr 23, 2018 at 7:10 AM, Stack  wrote:
>
> > The third release candidate for Apache HBase 2.0.0 is available for
> > downloading and testing.
> >
> > Artifacts are available here:
> >
> >  https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC2/
> >
> > Maven artifacts are available in the staging repository at:
> >
> > https://repository.apache.org/content/repositories/orgapachehbase-1213
> >
> > All artifacts are signed with my signing key 8ACC93D2, which is also
> > in the project KEYS file at
> >
> >  http://www.apache.org/dist/hbase/KEYS
> >
> > These artifacts were tagged 2.0.0RC2 at hash
> 7483b111e4da77adbfc8062b3b22cb
> > e7c2cb91c1
> >
> > Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0
> > Reference Guide before installing or upgrading for a list of
> > incompatibilities, major changes, and notable new features. Be aware that
> > according to our adopted Semantic Versioning guidelines[1], we've allow
> > ourselves to make breaking changes in this major version release. For
> > example, Coprocessors will need to be recast to fit more constrained CP
> > APIs and a rolling upgrade of an hbase-1.x install to hbase-2.x without
> > downtime is (currently) not possible. That said, a bunch of effort has
> been
> > expended mitigating differences; a hbase-1.x client can perform DML
> against
> > an hbase-2 cluster. A
> > bundled compatibility report showing difference from 1.2.6 may be of help
> > [3].
> >
> > For the full list of ~6k issues addressed, see [2]. There are also
> > CHANGES.md and RELEASENOTES.md in the root directory of the source
> tarball.
> >
> > Please take a few minutes to verify the release and vote on releasing it:
> >
> > [ ] +1 Release this package as Apache HBase 2.0.0
> > [ ] +0 no opinion
> > [ ] -1 Do not release this package because...
> >
> > This VOTE will run for one week and close Sunday, April 29, 2018 @ 21:00
> > PST.
> >
> > Thanks to the myriad who have helped out with this release,
> > Your 2.0.0 Release Manager
> >
> > 1. http://hbase.apache.org/2.0/book.html#hbase.versioning.post10
> > 2. https://s.apache.org/zwS9
> > 3.
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-2.0.0RC2/
> > compatibiliity_report_1.2.6vs2.0.0RC2.html
> >
>

Re: [ANNOUNCE] Please welcome Francis Liu to the HBase PMC

[Esteban Gutierrez]

Congrats Francis!!

--
Cloudera, Inc.


On Thu, Apr 12, 2018 at 2:10 PM, Eshcar Hillel 
wrote:

> Congrats Francis and good luck!
>
>
> On Wednesday, April 11, 2018, 11:04:17 PM GMT+3, Andrew Purtell <
> apurt...@apache.org> wrote:
>
>  On behalf of the Apache HBase PMC I am pleased to announce that Francis
> Liu has accepted our invitation to become a PMC member on the Apache
> HBase project. We appreciate Francis stepping up to take more
> responsibility in the HBase project. He has been an active contributor to
> HBase for many years and recently took over responsibilities as branch RM
> for branch-1.3.
>
> Please join me in welcoming Francis to the HBase PMC!
>
> --
> Best regards,
> Andrew
>
>

Re: [ANNOUNCE] New HBase committer Zach York

[Esteban Gutierrez]

Congrats, Zach!

--
Cloudera, Inc.


On Wed, Mar 7, 2018 at 12:37 PM, Peter Somogyi  wrote:

> Congratulations!
>
> On Wed, Mar 7, 2018 at 9:43 AM, Huaxiang Sun  wrote:
>
> > Congratulations, Zach!
> >
> >
> > > On Mar 7, 2018, at 9:26 AM, Umesh Agashe  wrote:
> > >
> > > Congratulations, Zach!
> > >
> > > On Wed, Mar 7, 2018 at 8:40 AM, Ted Yu  wrote:
> > >
> > >> Congratulations, Zach !
> > >>
> > >> On Wed, Mar 7, 2018 at 8:27 AM, Sean Busbey 
> wrote:
> > >>
> > >>> On behalf of the Apache HBase PMC, I am pleased to announce that Zach
> > >>> York has accepted the PMC's invitation to become a committer on the
> > >>> project.
> > >>>
> > >>> We appreciate all of Zach's great work thus far and look forward to
> > >>> continued involvement.
> > >>>
> > >>> Please join me in congratulating Zach!
> > >>>
> > >>
> >
> >
>

Re: [ANNOUNCE] Please welcome Ashish Singhi to the HBase PMC

[Esteban Gutierrez]

Congratulations, Ashish!!


--
Cloudera, Inc.


On Wed, Feb 28, 2018 at 3:56 PM, Andrew Purtell  wrote:

> Congratulations Ashish!
>
>
> On Wed, Feb 28, 2018 at 7:55 AM, Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Ashish
> > Singhi has accepted our invitation to become a PMC member on the
> > Apache HBase project. We appreciate Ashish stepping up to take more
> > responsibility in the HBase project.
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or
> > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > let us know!
> >
> > - busbey
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] Please welcome Guanghao Zhang to the HBase PMC

[Esteban Gutierrez]

Congrats, Guanghao!

--
Cloudera, Inc.


On Wed, Feb 28, 2018 at 3:56 PM, Andrew Purtell  wrote:

> Congratulations!
>
>
> On Wed, Feb 28, 2018 at 7:55 AM, Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that
> > Guanghao Zhang has accepted our invitation to become a PMC member on
> > the Apache HBase project. We appreciate Guanghao stepping up to take
> > more responsibility in the HBase project.
> >
> > As a reminder, if anyone would like to nominate another person as a
> > committer or PMC member, even if you are not currently a committer or
> > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > let us know!
> >
> > - busbey
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] Please welcome Mike Drob to the HBase PMC

[Esteban Gutierrez]

Excellent! congratulations, Mike!

--
Cloudera, Inc.


On Wed, Feb 28, 2018 at 10:38 AM, Tamás Pénzes  wrote:

> Congrats Mike!
>
> On Wed, Feb 28, 2018 at 8:13 AM, Ted Yu  wrote:
>
> > Congratulations, Mike !
> >
> > On Wed, Feb 28, 2018 at 7:54 AM, Sean Busbey  wrote:
> >
> > > On behalf of the Apache HBase PMC I am pleased to announce that Mike
> > > Drob has accepted our invitation to become a PMC member on the Apache
> > > HBase project. We appreciate Mike stepping up to take more
> > > responsibility in the HBase project.
> > >
> > >
> > > As a reminder, if anyone would like to nominate another person as a
> > > committer or PMC member, even if you are not currently a committer or
> > > PMC member, you can always drop a note to priv...@hbase.apache.org to
> > > let us know!
> > >
> > > - busbey
> > >
> >
>
>
>
> --
>
> *Tamás **Pénzes* | Engineering Manager
> e. tam...@cloudera.com
> cloudera.com 
>
> [image: Cloudera] 
>
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
>

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Esteban Gutierrez]

Congrats, Peter!

--
Cloudera, Inc.


On Thu, Feb 22, 2018 at 1:10 PM, Ted Yu  wrote:

> Congratulations, Peter !
>
> On Thu, Feb 22, 2018 at 11:08 AM, Sean Busbey  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Peter
> > Somogyi has accepted the PMC's invitation to become a committer on the
> > project.
> >
> > We appreciate all of Peter's great work thus far and look forward to
> > continued involvement.
> >
> > Please join me in congratulating Peter!
> >
>

[jira] [Created] (HBASE-19572) RegionMover should use the configured default port number and not the one from HConstants

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19572:
-

 Summary: RegionMover should use the configured default port number 
and not the one from HConstants
 Key: HBASE-19572
 URL: https://issues.apache.org/jira/browse/HBASE-19572
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez


The issue I ran into HBASE-19499 was due RegionMover not using the port used by 
{{hbase-site.xml}}. The tool should use the value used in the configuration 
before falling back to the hardcoded value 
{{HConstants.DEFAULT_REGIONSERVER_PORT}}



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

[jira] [Resolved] (HBASE-19499) RegionMover#stripMaster in RegionMover needs to handle HBASE-18511 gracefully

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-19499.
---
Resolution: Not A Bug

> RegionMover#stripMaster in RegionMover needs to handle HBASE-18511 gracefully
> -
>
> Key: HBASE-19499
> URL: https://issues.apache.org/jira/browse/HBASE-19499
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>    Reporter: Esteban Gutierrez
>
> Probably this is the first of few issues found during some tests with 
> RegionMover. After HBASE-13014 we ship the new RegionMover tool but it 
> currently assumes that master will be hosting regions so it attempts to 
> remove master from the list and that causes an issue similar to this:
> {code}
> 17/12/12 11:01:06 WARN util.RegionMover: Could not remove master from list of 
> RS
> java.lang.Exception: Server host1.example.com:22001 is not in list of online 
> servers(Offline/Incorrect)
>   at 
> org.apache.hadoop.hbase.util.RegionMover.stripServer(RegionMover.java:818)
>   at 
> org.apache.hadoop.hbase.util.RegionMover.stripMaster(RegionMover.java:757)
>   at 
> org.apache.hadoop.hbase.util.RegionMover.access$1800(RegionMover.java:78)
>   at 
> org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:339)
>   at 
> org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:314)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {code}
> Basicaly



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

[jira] [Created] (HBASE-19499) RegionMover#stripMaster is not longer necessary in RegionMover

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19499:
-

 Summary: RegionMover#stripMaster is not longer necessary in 
RegionMover
 Key: HBASE-19499
 URL: https://issues.apache.org/jira/browse/HBASE-19499
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Esteban Gutierrez


Probably this is the first of few issues found during some tests with 
RegionMover. After HBASE-13014 we ship the new RegionMover tool but it 
currently assumes that master will be hosting regions so it attempts to remove 
master from the list and that causes an issue similar to this:

{code}
17/12/12 11:01:06 WARN util.RegionMover: Could not remove master from list of RS
java.lang.Exception: Server host1.example.com:22001 is not in list of online 
servers(Offline/Incorrect)
at 
org.apache.hadoop.hbase.util.RegionMover.stripServer(RegionMover.java:818)
at 
org.apache.hadoop.hbase.util.RegionMover.stripMaster(RegionMover.java:757)
at 
org.apache.hadoop.hbase.util.RegionMover.access$1800(RegionMover.java:78)
at 
org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:339)
at 
org.apache.hadoop.hbase.util.RegionMover$Unload.call(RegionMover.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}

Basicaly



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

[jira] [Created] (HBASE-19391) Calling HRegion#initializeRegionInternals from a region replica can still re-create a region directory

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19391:
-

 Summary: Calling HRegion#initializeRegionInternals from a region 
replica can still re-create a region directory
 Key: HBASE-19391
 URL: https://issues.apache.org/jira/browse/HBASE-19391
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


This is a follow up from HBASE-18024. There stills a chance that attempting to 
open a region that is not the default region replica can still create a GC'd 
region directory by the CatalogJanitor causing inconsistencies with hbck.



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

[jira] [Created] (HBASE-19390) Revert to older version of Jetty 9.3

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19390:
-

 Summary: Revert to older version of Jetty 9.3 
 Key: HBASE-19390
 URL: https://issues.apache.org/jira/browse/HBASE-19390
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez


As discussed in HBASE-19256 we will have to temporarily revert to Jetty 9.3 due 
existing issues with 9.4 and Hadoop3. Once HBASE-19256 is resolved we can 
revert to 9.4.



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

[jira] [Created] (HBASE-19352) Port HADOOP-10379: Protect authentication cookies with the HttpOnly and Secure flags

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19352:
-

 Summary: Port HADOOP-10379: Protect authentication cookies with 
the HttpOnly and Secure flags
 Key: HBASE-19352
 URL: https://issues.apache.org/jira/browse/HBASE-19352
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez


This came via a security scanner, since we have a fork of HttpServer2 in HBase 
we should include it too.



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

[jira] [Resolved] (HBASE-18987) Raise value of HConstants#MAX_ROW_LENGTH

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-18987.
---
Resolution: Later

Solving as later since we could only do this with a new HFile format.

> Raise value of HConstants#MAX_ROW_LENGTH
> 
>
> Key: HBASE-18987
> URL: https://issues.apache.org/jira/browse/HBASE-18987
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Esteban Gutierrez
>    Assignee: Esteban Gutierrez
>Priority: Minor
> Attachments: HBASE-18987.master.001.patch, 
> HBASE-18987.master.002.patch
>
>
> Short.MAX_VALUE hasn't been a problem for a long time but one of our 
> customers ran into an  edgy case when the midKey used for the split point was 
> very close to Short.MAX_VALUE. When the split is submitted, we attempt to 
> create the new two daughter regions and we name those regions via 
> {{HRegionInfo.createRegionName()}} in order to be added to META. 
> Unfortunately, since {{HRegionInfo.createRegionName()}} uses midKey as the 
> startKey {{Put}} will fail since the row key length will now fail checkRow 
> and thus causing the split to fail.
> I tried a couple of alternatives to address this problem, e.g. truncating the 
> startKey. But the number of changes in the code doesn't justify for this edge 
> condition. Since we already use {{Integer.MAX_VALUE - 1}} for 
> {{HConstants#MAXIMUM_VALUE_LENGTH}} it should be ok to use the same limit for 
> the maximum row key. 



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

[jira] [Created] (HBASE-19309) Lower HConstants#MAX_ROW_LENGTH as guardrail in order to avoid HBASE-18987

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-19309:
-

 Summary: Lower HConstants#MAX_ROW_LENGTH as guardrail in order to 
avoid HBASE-18987
 Key: HBASE-19309
 URL: https://issues.apache.org/jira/browse/HBASE-19309
 Project: HBase
  Issue Type: Bug
  Components: HFile, regionserver
Reporter: Esteban Gutierrez


As discussed in HBASE-18987. A problem of having a row about the maximum size 
of a row (Short.MAX_VALUE) is when a split happens, there is a possibility that 
the midkey could be that row and the Put created to add the new entry in META 
will exceed the maximum row size since the new row key will include the table 
name and that will cause the split to abort. Since is not possible to raise 
that row key size in HFileV3, a reasonable solution is to reduce the maximum 
size of row key in order to avoid exceeding Short.MAX_VALUE.



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

Re: [ANNOUNCE] New HBase committer Lars Francke

[Esteban Gutierrez]

Congrats Lars F! well deserved!

--
Cloudera, Inc.


On Wed, Oct 25, 2017 at 3:26 PM, Andrew Purtell  wrote:

> Congratulations and welcome!
>
>
> On Wed, Oct 25, 2017 at 12:56 PM, Lars George 
> wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Lars
> > Francke has accepted the PMC's invitation to become a committer on the
> > project.
> >
> > We appreciate all of Lars' great work thus far and look forward to
> > continued involvement.
> >
> > Please join me in congratulating LarsF! (Opting to use last name
> > initials as we now have three Lars' as committers)
> >
> > --
> > Best regards,
> > LarsG
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

[jira] [Created] (HBASE-18987) Raise value of HConstants#MAX_ROW_LENGTH

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-18987:
-

 Summary: Raise value of HConstants#MAX_ROW_LENGTH
 Key: HBASE-18987
 URL: https://issues.apache.org/jira/browse/HBASE-18987
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 1.0.0, 2.0.0
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez
Priority: Minor


Short.MAX_VALUE hasn't been a problem for a long time but one of our customers 
ran into an  edgy case when the midKey used for the split point was very close 
to Short.MAX_VALUE. When the split is submitted, we attempt to create the new 
two daughter regions and we name those regions via 
{{HRegionInfo.createRegionName()}} in order to be added to META. Unfortunately, 
since {{HRegionInfo.createRegionName()}} uses midKey as the startKey {{Put}} 
will fail since the row key length will now fail checkRow and thus causing the 
split to fail.

I tried a couple of alternatives to address this problem, e.g. truncating the 
startKey. But the number of changes in the code doesn't justify for this edge 
condition. Since we already use {{Integer.MAX_VALUE - 1}} for 
{{HConstants#MAXIMUM_VALUE_LENGTH}} it should be ok to use the same limit for 
the maximum row key. 



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

Re: Welcome Chia-Ping Tsai to the HBase PMC

[Esteban Gutierrez]

Congrats  Chia-Ping! and Welcome!

--
Cloudera, Inc.


On Fri, Sep 29, 2017 at 3:52 PM, Guanghao Zhang  wrote:

> Congratulations!
>
> 2017-09-30 6:38 GMT+08:00 Andrew Purtell :
>
> > Congratulations, Chia-Ping! Welcome to the PMC.
> >
> > On Fri, Sep 29, 2017 at 3:19 PM, Misty Stanley-Jones 
> > wrote:
> >
> > > The HBase PMC is delighted to announce that Chia-Ping Tsai has agreed
> to
> > > join
> > > the HBase PMC, and help to make the project run smoothly. Chia-Ping
> > became
> > > an
> > > HBase committer over 6 months ago, based on long-running participate in
> > the
> > > HBase project, a consistent record of resolving HBase issues, and
> > > contributions
> > > to testing and performance.
> > >
> > > Thank you for stepping up to serve, Chia-Ping!
> > >
> > > As a reminder, if anyone would like to nominate another person as a
> > > committer or PMC member, even if you are not currently a committer or
> PMC
> > > member, you can always drop a note to priv...@hbase.apache.org to let
> us
> > > know!
> > >
> > > Thanks,
> > > Misty (on behalf of the HBase PMC)
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>

Re: Please congratulate our new PMC Chair Misty Stanley-Jones

[Esteban Gutierrez]

Thats awesome! Congratulations, Misty!



--
Cloudera, Inc.


On Fri, Sep 22, 2017 at 11:27 AM, Alexander Leblang <
alex.lebl...@cloudera.com> wrote:

> Congrats Misty! Well done!
> On Fri, Sep 22, 2017 at 11:25 AM Wei-Chiu Chuang 
> wrote:
>
> > Congrats! Misty!!
> >
> > On Fri, Sep 22, 2017 at 7:50 AM, Jimmy Xiang  wrote:
> >
> > > Congrats! Misty!!
> > >
> > > On Fri, Sep 22, 2017 at 7:16 AM, Pankaj kr 
> wrote:
> > >
> > > > Congratulations Misty..!! :)
> > > >
> > > >
> > > > -Pankaj-
> > > >
> > > >
> > > > -Original Message-
> > > > From: Andrew Purtell [mailto:apurt...@apache.org]
> > > > Sent: Friday, September 22, 2017 3:08 AM
> > > > To: dev@hbase.apache.org; u...@hbase.apache.org
> > > > Subject: Please congratulate our new PMC Chair Misty Stanley-Jones
> > > >
> > > > At today's meeting of the Board, Special Resolution B changing the
> > HBase
> > > > project Chair to Misty Stanley-Jones was passed unanimously.
> > > >
> > > > Please join me in congratulating Misty on her new role!
> > > >
> > > > ​(If you need any help or advice please don't hesitate to ping me,
> > Misty,
> > > > but I suspect you'll do just fine and won't need it.)​
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > >
> >
> >
> >
> > --
> > A very happy Hadoop contributor
> >
>

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

[Esteban Gutierrez]

Thanks Stack!

--
Cloudera, Inc.


On Mon, Aug 14, 2017 at 1:05 PM, Stack <st...@duboce.net> wrote:

> On Fri, Aug 4, 2017 at 10:00 AM, Esteban Gutierrez <este...@cloudera.com>
> wrote:
>
> > 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?
> >
> >
> Yes. I'd say this should be a blocker Esteban. Filed HBASE-18596.
> Thanks,
> S
>
>
>
>
>
> > Thanks for starting this discussion Stack,
> >
> > esteban.
> >
> > --
> > Cloudera, Inc.
> >
> >
> > On Fri, Aug 4, 2017 at 1:05 AM, stack <saint@gmail.com> wrote:
> >
> > > Thanks Zach for clarification. Let me work up a list and then come back
> > to
> > > this thread.  Jira needs an edit pass to.
> > >
> > > S
> > >
> > > On Aug 3, 2017 23:54, "Zach York" <zyork.contribut...@gmail.com>
> wrote:
> > >
> > > This kinda helps, but these seem more like expectations. I was going
> more
> > > for things like HFile format changed, meta table structure changed,
> > > coprocessor implementations changed (these are just examples, I don't
> > know
> > > if any of these actually changed).
> > >
> > > More technical differences between branch-1 and branch-2 which then can
> > > help us get the right expectations for compatibility.
> > >
> > > On Wed, Aug 2, 2017 at 6:34 PM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Wed, Aug 2, 2017 at 5:25 PM, Zach York <
> > zyork.contribut...@gmail.com>
> > > > wrote:
> > > >
> > > > > Do we know what the major pain points for migration are? Can we
> > discuss
> > > > > that/get a list going?
> > > > >
> > > > >
> > > > Here's a few in outline:
> > > >
> > > > + There is issue of formats, of hbase-2.x being able to read
> hbase-1.x
> > > data
> > > > whether from HDFS or ZooKeeper or off the wire.
> > > > + An hbase-1.x client should be able to Get/Put and Scan an hbase-2.x
> > > > cluster; no holes in the API or unintelligible serializations.
> > > > + There is then the little dance that has us rolling restart from an
> > > > hbase-1.x cluster to hbase-2.x; i.e. upgrade master first and then it
> > > will
> > > > assign regions to the new hbase-2.x regionservers as they come on
> line.
> > > > TBD.
> > > >
> > > > Is this what you mean sir?
> > > >
> > > > S
> > > >
> > > >
> > > > > I think without that knowledge it is hard (for me at least :) ) to
> > > > > determine where we should set our sights in terms of migration.
> > > > >
> > > > > Thanks,
> > > > > Zach
> > > > >
> > > > > On Wed, Aug 2, 2017 at 4:38 PM, Stack <st...@duboce.net> wrote:
> > > > >
> > > > > > What are our expectations regards compatibility between hbase1
> and
> > > > > hbase2?
> > > > > >
> > > > > > Lets have a chat about it. Here are some goal posts.
> > > > > >
> > > > > > + You have to upgrade to hbase-1.x before you can migrate to
> > hbase-2.
> > > > No
> > > > > > migration from < hbase-1 (Is this too onerous? Should we support
> > 0.98
> > > > =>
> > > > > > 2.0?).
> > > > > > + You do NOT have to upgrade to the latest release of hbase1 to
> > > migrate
> > > > > to
> > > > > > hbase2; being up on hbase-1.0.0+ will be sufficient.
> > > > > > + You'll have to update your hbase1 coprocessors to deploy them
> on
> > > > > hbase2.
> > > > > > A bunch of CP API has/will change by the time hbase2 comes out;
> > e.g.
> > > > > > watching for region split on RegionServer no longer makes sense
> > given
> > > > > > Master runs all splits now.
> > > > > > + An hbase1 client can run against an hbase2 cluster but it will
> > only
> > > > be
> > > > > > able to do DML (Get/Put/Scan, etc.). We do not allow being able
> to
> > do
> > > > > admin
> > > > > > ops using an hbase1 Admin client against an hbase2 cluster. We
> have
> > > > some
> > > > > > egregious API violations in branch-1; e.g. we have protobuf in
> our
> > > API
> > > > > (See
> > > > > > HBASE-15607). The notion is that we can't afford a deprecation
> > cycle
> > > > > > purging this stuff from our Admin API.
> > > > > >
> > > > > > What you all think?
> > > > > >
> > > > > > St.Ack
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (HBASE-18563) Fix RAT License complaint about website jenkins scripts

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-18563:
-

 Summary: Fix RAT License complaint about website jenkins scripts
 Key: HBASE-18563
 URL: https://issues.apache.org/jira/browse/HBASE-18563
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez
Priority: Trivial


{{2 Unknown Licenses

*

Files with unapproved licenses:

  dev-support/jenkins-scripts/check-website-links.sh
  dev-support/jenkins-scripts/generate-hbase-website.sh

*
}}



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

Re: [DISCUSS] hbase-2.0.0 compatibility expectations

[Esteban Gutierrez]

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?

Thanks for starting this discussion Stack,

esteban.

--
Cloudera, Inc.


On Fri, Aug 4, 2017 at 1:05 AM, stack  wrote:

> Thanks Zach for clarification. Let me work up a list and then come back to
> this thread.  Jira needs an edit pass to.
>
> S
>
> On Aug 3, 2017 23:54, "Zach York"  wrote:
>
> This kinda helps, but these seem more like expectations. I was going more
> for things like HFile format changed, meta table structure changed,
> coprocessor implementations changed (these are just examples, I don't know
> if any of these actually changed).
>
> More technical differences between branch-1 and branch-2 which then can
> help us get the right expectations for compatibility.
>
> On Wed, Aug 2, 2017 at 6:34 PM, Stack  wrote:
>
> > On Wed, Aug 2, 2017 at 5:25 PM, Zach York 
> > wrote:
> >
> > > Do we know what the major pain points for migration are? Can we discuss
> > > that/get a list going?
> > >
> > >
> > Here's a few in outline:
> >
> > + There is issue of formats, of hbase-2.x being able to read hbase-1.x
> data
> > whether from HDFS or ZooKeeper or off the wire.
> > + An hbase-1.x client should be able to Get/Put and Scan an hbase-2.x
> > cluster; no holes in the API or unintelligible serializations.
> > + There is then the little dance that has us rolling restart from an
> > hbase-1.x cluster to hbase-2.x; i.e. upgrade master first and then it
> will
> > assign regions to the new hbase-2.x regionservers as they come on line.
> > TBD.
> >
> > Is this what you mean sir?
> >
> > S
> >
> >
> > > I think without that knowledge it is hard (for me at least :) ) to
> > > determine where we should set our sights in terms of migration.
> > >
> > > Thanks,
> > > Zach
> > >
> > > On Wed, Aug 2, 2017 at 4:38 PM, Stack  wrote:
> > >
> > > > What are our expectations regards compatibility between hbase1 and
> > > hbase2?
> > > >
> > > > Lets have a chat about it. Here are some goal posts.
> > > >
> > > > + You have to upgrade to hbase-1.x before you can migrate to hbase-2.
> > No
> > > > migration from < hbase-1 (Is this too onerous? Should we support 0.98
> > =>
> > > > 2.0?).
> > > > + You do NOT have to upgrade to the latest release of hbase1 to
> migrate
> > > to
> > > > hbase2; being up on hbase-1.0.0+ will be sufficient.
> > > > + You'll have to update your hbase1 coprocessors to deploy them on
> > > hbase2.
> > > > A bunch of CP API has/will change by the time hbase2 comes out; e.g.
> > > > watching for region split on RegionServer no longer makes sense given
> > > > Master runs all splits now.
> > > > + An hbase1 client can run against an hbase2 cluster but it will only
> > be
> > > > able to do DML (Get/Put/Scan, etc.). We do not allow being able to do
> > > admin
> > > > ops using an hbase1 Admin client against an hbase2 cluster. We have
> > some
> > > > egregious API violations in branch-1; e.g. we have protobuf in our
> API
> > > (See
> > > > HBASE-15607). The notion is that we can't afford a deprecation cycle
> > > > purging this stuff from our Admin API.
> > > >
> > > > What you all think?
> > > >
> > > > St.Ack
> > > >
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Mike Drob

[Esteban Gutierrez]

Congrats, Mike!

--
Cloudera, Inc.


On Tue, Aug 1, 2017 at 12:33 PM, Anoop John  wrote:

> Congrats Mike...
>
> On Tue, Aug 1, 2017 at 10:41 PM, Jingcheng Du  wrote:
> > Congratulations!
> >
> > 2017-08-02 1:08 GMT+08:00 Umesh Agashe :
> >
> >> Congrats Mike!
> >>
> >> On Tue, Aug 1, 2017 at 9:52 AM, Amit Patel 
> >> wrote:
> >>
> >> > Congrats Mike !
> >> >
> >> > > On Aug 1, 2017, at 9:46 AM, ramkrishna vasudevan <
> >> > ramkrishna.s.vasude...@gmail.com> wrote:
> >> > >
> >> > > Welcome Mike !!!
> >> > >
> >> > >> On Tue, Aug 1, 2017 at 10:14 PM, Chia-Ping Tsai <
> chia7...@apache.org>
> >> > wrote:
> >> > >>
> >> > >> Welcome.  Mike!
> >> > >>
> >> > >>> On 2017-08-01 23:38, Josh Elser  wrote:
> >> > >>> On behalf of the Apache HBase PMC, I'm pleased to announce that
> Mike
> >> > >>> Drob has accepted the PMC's invitation to become a committer.
> >> > >>>
> >> > >>> Mike has been doing some great things lately in the project and
> this
> >> is
> >> > >>> a simple way that we can express our thanks. As my boss likes to
> tell
> >> > >>> me: the reward for a job well-done is more work to do! We're all
> >> > looking
> >> > >>> forward to your continued involvement :)
> >> > >>>
> >> > >>> Please join me in congratulating Mike!
> >> > >>>
> >> > >>> - Josh
> >> > >>>
> >> > >>
> >> >
> >>
>

Re: [ANNOUNCE] New HBase committer Huaxiang Sun

[Esteban Gutierrez]

Congratulations and well deserved, Huaxiang!

esteban.

--
Cloudera, Inc.


On Mon, Jun 19, 2017 at 1:21 PM, Karan Mehta  wrote:

> Congratulations Huaxiang!!
>
> Karan Mehta
> ᐧ
>
> On Mon, Jun 19, 2017 at 1:18 PM, Alexander Leblang <
> alex.lebl...@cloudera.com> wrote:
>
> > Congratulations Huaxiang!
> >
> > On Mon, Jun 19, 2017 at 12:30 PM, Sean Busbey  wrote:
> >
> > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > > Huaxiang Sun has accepted the PMC's invitation to become a committer
> > > on the project. We appreciate all of Huaxiang's great work thus far
> > > and look forward to continued involvement.
> > >
> > > Please join me in congratulating Huaxiang!
> > >
> >
>

Re: [ANNOUNCE] New HBase committer Allan Yang

[Esteban Gutierrez]

Congrats, Allan!


--
Cloudera, Inc.


On Fri, Jun 9, 2017 at 10:06 AM, Andrew Purtell  wrote:

> Congratulations and welcome, Allan!
>
> On Thu, Jun 8, 2017 at 8:49 PM, Yu Li  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Allan
> Yang
> > has accepted the PMC's invitation to become a committer on the
> > project. We appreciate all of Allan's generous contributions thus far and
> > look forward to his continued involvement.
> >
> > Congratulations and welcome, Allan!
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>

[jira] [Created] (HBASE-18177) FanOutOneBlockAsyncDFSOutputHelper fails to compile against Hadoop 3

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-18177:
-

 Summary: FanOutOneBlockAsyncDFSOutputHelper fails to compile 
against Hadoop 3
 Key: HBASE-18177
 URL: https://issues.apache.org/jira/browse/HBASE-18177
 Project: HBase
  Issue Type: Bug
  Components: wal
Reporter: Esteban Gutierrez


After HDFS-10996 ClientProtocol#create() needs to specify the erasure code 
policy to use. In the meantime we should add a workaround to 
FanOutOneBlockAsyncDFSOutputHelper to be able to compile against Hadoop 3 and 
Hadoop 2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-18025) CatalogJanitor should collect outdated RegionStates from the AM

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-18025:
-

 Summary: CatalogJanitor should collect outdated RegionStates from 
the AM
 Key: HBASE-18025
 URL: https://issues.apache.org/jira/browse/HBASE-18025
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


I don't think this will matter on the long run for HBase 2, but at least in 
branch-1 and the current master we keep in multiple places copies of the region 
states in the master and this copies include information like the HRI. A 
problem that we have observed is when region replicas are being used and there 
is a split, the region replica from parent doesn't get collected from the 
region states and when the balancer tries to assign the old parent region 
replica, this will cause the RegionServer to create a new HRI with the details 
of the parent causing an inconstancy (see HBASE-18024).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-18024) HRegion#initializeRegionInternals should not re-create .hregioninfo file when the region directory no longer exists

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-18024:
-

 Summary: HRegion#initializeRegionInternals should not re-create 
.hregioninfo file when the region directory no longer exists
 Key: HBASE-18024
 URL: https://issues.apache.org/jira/browse/HBASE-18024
 Project: HBase
  Issue Type: Bug
  Components: Region Assignment, regionserver
Affects Versions: 1.2.5, 1.3.1, 1.4.0
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


When a RegionSever attempts to open a region, during initialization the RS 
tries to open the {{/data///.hregioninfo}} file, 
however if the {{.hregioninfofile}} doesn't exist, the RegionServer will create 
a new one on {{HRegionFileSystem#checkRegionInfoOnFilesystem}}. A side effect 
of that tools like hbck will incorrectly assume an inconsistency due the 
presence of this new {{.hregioninfofile}}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [ANNOUNCE] New HBase committer Chia-Ping Tsai

[Esteban Gutierrez]

Congrats and welcome, Chia-Ping!

--
Cloudera, Inc.


On Sun, Mar 19, 2017 at 6:18 PM, Guanghao Zhang  wrote:

> Congratulations！
>
> 2017-03-20 9:08 GMT+08:00 宾莉金 or binlijin :
>
> > Congratulations and welcome!
> >
> > 2017-03-19 15:43 GMT+08:00 Phil Yang :
> >
> > > Congratulations!
> > >
> > > Thanks,
> > > Phil
> > >
> > >
> > > 2017-03-18 20:38 GMT+08:00 Ashish Singhi  com
> > >:
> > >
> > > > Many Congratulations !
> > > >
> > > > On Sat, Mar 18, 2017 at 4:00 AM, Anoop John 
> > > wrote:
> > > >
> > > > > On behalf of the Apache HBase PMC, I am pleased to announce that
> > > > Chia-Ping
> > > > > Tsai
> > > > > has accepted the PMC's invitation to become a committer on the
> > project.
> > > > We
> > > > > appreciate all of his contributions thus far and look forward
> > > > > to his continued involvement.
> > > > >
> > > > > Congratulation and welcome Chia-Ping Tsai!
> > > > >
> > > > > -Anoop-
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > *Best Regards,*
> >  lijin bin
> >
>

[jira] [Created] (HBASE-17799) HBCK region boundaries check can return false negatives when IOExceptions are thrown

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17799:
-

 Summary: HBCK region boundaries check can return false negatives 
when IOExceptions are thrown
 Key: HBASE-17799
 URL: https://issues.apache.org/jira/browse/HBASE-17799
 Project: HBase
  Issue Type: Bug
  Components: hbck
Affects Versions: 2.0.0, 1.4.0, 1.3.1, 1.2.5
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


When enabled, HBaseFsck#checkRegionBoundaries will crawl all HFiles across all 
namespaces and tables when {{-boundaries}} is specified. However if an 
IOException is thrown by accessing a corrupt HFile, an un-handled HLink or by 
any other reason, we will only log the exception and stop crawling the HFiles 
and potentially reporting the wrong result.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: ANNOUNCE: Good news!!!! Two new PMC and a new Committer!

[Esteban Gutierrez]

Amazing! Congratulations to all of you guys!

esteban.

--
Cloudera, Inc.


On Fri, Mar 17, 2017 at 8:58 AM, Andrew Purtell 
wrote:

> Congratulations and welcome, all!
>
> > On Mar 17, 2017, at 6:04 AM, Jonathan Hsieh  wrote:
> >
> > Yay!
> >
> >> On Thu, Mar 16, 2017 at 10:37 PM, Stack  wrote:
> >>
> >> Josh Elser and Jing Chen (Jerry) have both been added to the HBase PMC.
> >> These lads have been stellar helping the project along; Jerry for a good
> >> few years now and Josh, though less time served, has made up for the
> lack
> >> with style. It makes sense that they be made PMCers!
> >>
> >> Let me take this opportunity while I have your attention to also welcome
> >> Eshcar Hillel as a Committer on Apache HBase. We are very glad to have
> her
> >> on-board. She's a brainbox who has been working on the inmemory
> compaction
> >> project among other things and is without fear when it comes to taking a
> >> deep dive into crud!
> >>
> >> Welcome aboard Josh, Jing Chen He, and Eshcar!
> >>
> >> St.Ack
> >>
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Tech Lead, Software Engineer, Cloudera
> > // j...@cloudera.com // @jmhsieh
>

[jira] [Created] (HBASE-17756) We should have better introspection of HFiles

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17756:
-

 Summary: We should have better introspection of HFiles
 Key: HBASE-17756
 URL: https://issues.apache.org/jira/browse/HBASE-17756
 Project: HBase
  Issue Type: Brainstorming
  Components: HFile
Reporter: Esteban Gutierrez


[~saint@gmail.com] was suggesting to use DataSketches 
(https://datasketches.github.io) in order to write additional statistics to the 
HFiles. This could be used to improve our split decisions, troubleshooting or 
potentially do other interesting analysis without having to perform full table 
scans. The statistics could be stored as part of the HFile but we could 
initially improve the visibility of the data by adding some statistics to 
HFilePrettyPrinter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17755) CellBasedKeyBlockIndexReader#midkey should exhaust search of the target middle key on skewed regions

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17755:
-

 Summary: CellBasedKeyBlockIndexReader#midkey should exhaust search 
of the target middle key on skewed regions
 Key: HBASE-17755
 URL: https://issues.apache.org/jira/browse/HBASE-17755
 Project: HBase
  Issue Type: Bug
  Components: HFile
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez


We have always been returning the middle key of the the block index regardless 
the distribution of the data on an HFile. A side effect of that approach is 
that when millions of rows share the same key its quite easy to run into a 
situation when the start key is equal to the middle key or when the end key is 
equal to the middle key making that HFile nearly impossible to split until 
enough data is written into the region and the middle key shifts to another row 
or when an operator uses a custom split point in order to split that region. 

Instead we should exhaust the search of the middle key in the block index in 
order to be able to split an HFile earlier when possible even if our edge case 
is to serve a region that could hold a single key with millions of versions of 
a row or with millions of qualifiers on the same row.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-17679) Log arguments passed to hbck

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-17679.
---
Resolution: Duplicate

Duplicate of HBASE-12678. Perhaps PrintingErrorReporter sends to stdout that 
information while our log4j properties make the console write to stderr. 

> Log arguments passed to hbck
> 
>
> Key: HBASE-17679
> URL: https://issues.apache.org/jira/browse/HBASE-17679
> Project: HBase
>  Issue Type: Bug
>    Reporter: Esteban Gutierrez
>    Assignee: Esteban Gutierrez
>Priority: Trivial
>
> Sometimes hbck arguments get lost and we only end up with the output of hbck. 
> This should log some basic info about our arguments passed to hbck for better 
> supportability. Additional server side logging will be added later on HBase 
> Admin calls in a different JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-17679) Log arguments passed to hbck

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17679:
-

 Summary: Log arguments passed to hbck
 Key: HBASE-17679
 URL: https://issues.apache.org/jira/browse/HBASE-17679
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez
Priority: Trivial


Sometimes hbck arguments get lost and we only end up with the output of hbck. 
This should log some basic info about our arguments passed to hbck for better 
supportability. Additional server side logging will be added later on HBase 
Admin calls in a different JIRA.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: looking for reviews on small security patches

[Esteban Gutierrez]

done.

--
Cloudera, Inc.


On Fri, Feb 17, 2017 at 5:50 AM, Sean Busbey  wrote:

> Hi folks!
>
> I'm hoping to get reviews on these two issues:
>
> Unvalidated Redirect in HMaster
> https://issues.apache.org/jira/browse/HBASE-15328
>
> table status page should escape values that may contain arbitrary
> characters.
> https://issues.apache.org/jira/browse/HBASE-17561
>
>
> I'd like to use some time over the long weekend to get a new 1.2.5
> release candidate posted, but I'd like to see these two issues closed
> out first.
>

[jira] [Created] (HBASE-17622) Add hbase-metrics package to TableMapReduceUtil

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17622:
-

 Summary: Add hbase-metrics package to TableMapReduceUtil
 Key: HBASE-17622
 URL: https://issues.apache.org/jira/browse/HBASE-17622
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 2.0.0
Reporter: Esteban Gutierrez
Priority: Trivial


HBASE-9774 moved our metrics to its own package recently, unfortunately running 
a MR job against snapshots will fail since  
org.apache.hadoop.hbase.metrics.impl.FastLongHistogram is not present in the 
classpath and is needed by the ClientSideRegionScanner (HStore keeps track 
cache statistics from LruBlockCache).  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: would clean up znodes in HBASE 0.94 version cause any problem?

[Esteban Gutierrez]

Stephen,

well... if we ignore replication it should be ok, right? also it depends if
this is a secure HBase cluster with custom ACLs for the znodes.

esteban.


--
Cloudera, Inc.


On Sun, Jan 29, 2017 at 10:56 AM, Stephen Jiang 
wrote:

> I know cleaning up znode in a late verion of HBase (1.x) would not have a
> problem.  Restarting cluster would recreate znodes.  For HBase 0.94, is
> this still true?  (my guess is yes, but I'd like to check)
>
> Thanks
> Stephen
>

[jira] [Created] (HBASE-17544) Expose metrics for the CatalogJanitor

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17544:
-

 Summary: Expose metrics for the CatalogJanitor
 Key: HBASE-17544
 URL: https://issues.apache.org/jira/browse/HBASE-17544
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez


Currently there is other way to know what the CatalogJanitor is doing except in 
the logs. We should have better visibility of when it was the last time the 
CatalogJanitor ran, how long it took to scan meta, the number of merged and 
parent regions cleaned on the last run, and if in maintenance mode (see 
HBASE-16008). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 答复: [ANNOUNCE] New HBase committer Guanghao Zhang

[Esteban Gutierrez]

Congratulations and welcome Guanghao!

--
Cloudera, Inc.


On Wed, Dec 21, 2016 at 5:29 PM, Honghua Feng 冯宏华 
wrote:

> Congratulations and welcome Guanghao！
> 
> 发件人: saint@gmail.com  代表 Stack 
> 发送时间: 2016年12月21日 2:01
> 收件人: HBase Dev List
> 抄送: hbase-user
> 主题: Re: [ANNOUNCE] New HBase committer Guanghao Zhang
>
> Welcome Guanghao!
> St.Ack
>
> On Mon, Dec 19, 2016 at 5:37 PM, Duo Zhang  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Guanghao
> > Zhang has accepted the PMC's invitation to become a committer on the
> > project. We appreciate all of Guanghao's generous contributions thus far
> > and look forward to his continued involvement.
> >
> > Congratulations and welcome, Guanghao!
> >
>

[jira] [Created] (HBASE-17305) Two active HBase Masters can run at the same time under certain circumstances

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17305:
-

 Summary: Two active HBase Masters can run at the same time under 
certain circumstances 
 Key: HBASE-17305
 URL: https://issues.apache.org/jira/browse/HBASE-17305
 Project: HBase
  Issue Type: Bug
  Components: master
Affects Versions: 2.0.0
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez
Priority: Critical


This needs a little more investigation, but we found a very edgy case when the 
active master is restarted and a stand-by master tries to become active, 
however the original active master was able to become the active master again 
and just before the standby master passed the point of the transition to become 
active we ended up with two active masters running at the same time. Assuming 
the clock on both masters were accurate to milliseconds, this race happened in 
less than 85ms. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [ANNOUNCE] New HBase Committer Josh Elser

[Esteban Gutierrez]

Congrats and welcome, Josh!

esteban.


--
Cloudera, Inc.


On Sun, Dec 11, 2016 at 10:17 PM, Yu Li  wrote:

> Congratulations and welcome!
>
> Best Regards,
> Yu
>
> On 12 December 2016 at 12:47, Mikhail Antonov 
> wrote:
>
> > Congratulations Josh!
> >
> > -Mikhail
> >
> > On Sun, Dec 11, 2016 at 5:20 PM, 张铎  wrote:
> >
> > > Congratulations!
> > >
> > > 2016-12-12 9:03 GMT+08:00 Jerry He :
> > >
> > > > Congratulations , Josh!
> > > >
> > > > Good work on the PQS too.
> > > >
> > > > Jerry
> > > >
> > > > On Sun, Dec 11, 2016 at 12:14 PM, Josh Elser 
> > wrote:
> > > >
> > > > > Thanks, all. I'm looking forward to continuing to work with you
> all!
> > > > >
> > > > >
> > > > > Nick Dimiduk wrote:
> > > > >
> > > > >> On behalf of the Apache HBase PMC, I am pleased to announce that
> > Josh
> > > > >> Elser
> > > > >> has accepted the PMC's invitation to become a committer on the
> > > project.
> > > > We
> > > > >> appreciate all of Josh's generous contributions thus far and look
> > > > forward
> > > > >> to his continued involvement.
> > > > >>
> > > > >> Allow me to be the first to congratulate and welcome Josh into his
> > new
> > > > >> role!
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
> >
>

Re: [ANNOUNCE] New HBase committer Phil Yang

[Esteban Gutierrez]

Congratulations, Phil!


--
Cloudera, Inc.


On Tue, Nov 29, 2016 at 9:07 AM, Stack  wrote:

> Welcome Phil!
> St.Ack
>
> On Tue, Nov 29, 2016 at 1:49 AM, Duo Zhang  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Phil
> Yang
> > has accepted the PMC's invitation to become a committer on the project.
> We
> > appreciate all of Phil's generous contributions thus far and look forward
> > to his continued involvement.
> >
> > Congratulations and welcome, Phil!
> >
>

Re: [ANNOUNCE] New HBase committer Lijin Bin

[Esteban Gutierrez]

Congratulations and welcome, Lijin!

--
Cloudera, Inc.


On Tue, Nov 29, 2016 at 5:32 AM, Yu Li  wrote:

> Congratulations and welcome Lijin!
>
> Best Regards,
> Yu
>
> On 29 November 2016 at 17:48, Duo Zhang  wrote:
>
> > On behalf of the Apache HBase PMC, I am pleased to announce that Lijin
> > Bin(binlijin) has accepted the PMC's invitation to become a committer on
> > the project. We appreciate all of Lijin's generous contributions thus far
> > and look forward to his continued involvement.
> >
> > Congratulations and welcome, Lijin!
> >
>

[jira] [Resolved] (HBASE-9913) weblogic deployment project implementation under the mapreduce hbase reported a NullPointerException

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-9913.
--
Resolution: Duplicate

Fixed in HBASE-12491

> weblogic deployment project implementation under the mapreduce hbase reported 
> a NullPointerException
> 
>
> Key: HBASE-9913
> URL: https://issues.apache.org/jira/browse/HBASE-9913
> Project: HBase
>  Issue Type: Bug
>  Components: hadoop2, mapreduce
>Affects Versions: 0.94.10
> Environment: weblogic windows
>Reporter: 刘泓
> Attachments: TableMapReduceUtil.class, TableMapReduceUtil.java
>
>
> java.lang.NullPointerException
>   at java.io.File.(File.java:222)
>   at java.util.zip.ZipFile.(ZipFile.java:75)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.updateMap(TableMapReduceUtil.java:617)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.findOrCreateJar(TableMapReduceUtil.java:597)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.addDependencyJars(TableMapReduceUtil.java:557)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.addDependencyJars(TableMapReduceUtil.java:518)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.initTableMapperJob(TableMapReduceUtil.java:144)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.initTableMapperJob(TableMapReduceUtil.java:221)
>   at 
> org.apache.hadoop.hbase.mapreduce.TableMapReduceUtil.initTableMapperJob(TableMapReduceUtil.java:87)
>   at 
> com.easymap.ezserver6.map.source.hbase.convert.HBaseMapMerge.beginMerge(HBaseMapMerge.java:163)
>   at 
> com.easymap.ezserver6.app.servlet.EzMapToHbaseService.doPost(EzMapToHbaseService.java:32)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at 
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
>   at 
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
>   at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3594)
>   at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>   at 
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>   at 
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202)
>   at 
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108)
>   at 
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432)
>   at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
>   at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> > 
> my project deploy under weblogic11,and when i run hbase mapreduce，it throws a 
> NullPointerException.i found the method 
> TableMapReduceUtil.findContainingJar() returns null,so i debug it, 
> url.getProtocol() return "zip",but the file is a jar file,so the if condition:
>  if ("jar".equals(url.getProtocol()))  cann't run. so i add a if condition to 
> judge "zip" type



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-9925) Don't close a file if doesn't EOF while replicating

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-9925.
--
Resolution: Later

Resolving for later, we should better fix other replication bottlenecks before 
we hit some contention from the NN.

> Don't close a file if doesn't EOF while replicating
> ---
>
> Key: HBASE-9925
> URL: https://issues.apache.org/jira/browse/HBASE-9925
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Himanshu Vashishtha
>
> While doing replication, we open and close the WAL file _every_ time we read 
> entries to send. We could open/close the reader only when we hit EOF. That 
> would alleviate some NN load, especially on a write heavy cluster.
> This came while discussing our current open/close heuristic in replication 
> with [~jdcryans].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-9940) PerformanceEvaluation should have a test with many table options on (Bloom, compression, FAST_DIFF, etc.)

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-9940.
--
Resolution: Fixed

Most of the features requested by [~jmspaggi] are already present in 
PerformanceEvaluation. Created HBASE-17116 to address missing feature to 
configure block size.


> PerformanceEvaluation should have a test with many table options on (Bloom, 
> compression, FAST_DIFF, etc.)
> -
>
> Key: HBASE-9940
> URL: https://issues.apache.org/jira/browse/HBASE-9940
> Project: HBase
>  Issue Type: Bug
>  Components: Performance, test
>Affects Versions: 0.96.0, 0.94.13
>Reporter: Jean-Marc Spaggiari
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-17116) [PerformanceEvaluation] Add option to configure block size

[Esteban Gutierrez (JIRA)]

Esteban Gutierrez created HBASE-17116:
-

 Summary: [PerformanceEvaluation] Add option to configure block size
 Key: HBASE-17116
 URL: https://issues.apache.org/jira/browse/HBASE-17116
 Project: HBase
  Issue Type: Bug
  Components: tooling
Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.5
Reporter: Esteban Gutierrez
Priority: Trivial


Followup from HBASE-9940 to add option to configure block size for 
PerformanceEvaluation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-9968) Cluster is non operative if the RS carrying -ROOT- is expiring after deleting -ROOT- region transition znode and before adding it to online regions.

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-9968.
--
Resolution: Won't Fix

We no longer have {{-ROOT-}}

> Cluster is non operative if the RS carrying -ROOT- is expiring after deleting 
> -ROOT- region transition znode and before adding it to online regions.
> 
>
> Key: HBASE-9968
> URL: https://issues.apache.org/jira/browse/HBASE-9968
> Project: HBase
>  Issue Type: Bug
>  Components: Region Assignment
>Affects Versions: 0.94.11
>Reporter: rajeshbabu
>Assignee: rajeshbabu
>
> When we check whether the dead region is carrying root or meta, first we will 
> check any transition znode for the region is there or not. In this case it 
> got deleted. So from zookeeper we cannot find the region location. 
> {code}
> try {
>   data = ZKAssign.getData(master.getZooKeeper(), hri.getEncodedName());
> } catch (KeeperException e) {
>   master.abort("Unexpected ZK exception reading unassigned node for 
> region="
> + hri.getEncodedName(), e);
> }
> {code}
> Now we will check from the AssignmentManager whether its in online regions or 
> not
> {code}
> ServerName addressFromAM = getRegionServerOfRegion(hri);
> boolean matchAM = (addressFromAM != null &&
>   addressFromAM.equals(serverName));
> LOG.debug("based on AM, current region=" + hri.getRegionNameAsString() +
>   " is on server=" + (addressFromAM != null ? addressFromAM : "null") +
>   " server being checked: " + serverName);
> {code}
> From AM we will get null because  while adding region to online regions we 
> will check whether the RS is in onlineservers or not and if not we will not 
> add the region to online regions.
> {code}
>   if (isServerOnline(sn)) {
> this.regions.put(regionInfo, sn);
> addToServers(sn, regionInfo);
> this.regions.notifyAll();
>   } else {
> LOG.info("The server is not in online servers, ServerName=" + 
>   sn.getServerName() + ", region=" + regionInfo.getEncodedName());
>   }
> {code}
> Even though the dead regionserver carrying ROOT region, its returning false. 
> After that ROOT region never assigned.
> Here are the logs
> {code}
> 2013-11-11 18:04:14,730 INFO 
> org.apache.hadoop.hbase.catalog.RootLocationEditor: Unsetting ROOT region 
> location in ZooKeeper
> 2013-11-11 18:04:14,775 DEBUG 
> org.apache.hadoop.hbase.master.AssignmentManager: No previous transition plan 
> was found (or we are ignoring an existing plan) for -ROOT-,,0.70236052 so 
> generated a random one; hri=-ROOT-,,0.70236052, src=, 
> dest=HOST-10-18-40-69,60020,1384173244404; 1 (online=1, available=1) 
> available servers
> 2013-11-11 18:04:14,809 DEBUG 
> org.apache.hadoop.hbase.master.AssignmentManager: Assigning region 
> -ROOT-,,0.70236052 to HOST-10-18-40-69,60020,1384173244404
> 2013-11-11 18:04:18,375 DEBUG 
> org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation: 
> Looked up root region location, 
> connection=org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation@12133926;
>  serverName=HOST-10-18-40-69,60020,1384173244404
> 2013-11-11 18:04:26,213 DEBUG 
> org.apache.hadoop.hbase.master.AssignmentManager: Handling 
> transition=RS_ZK_REGION_OPENED, server=HOST-10-18-40-69,60020,1384173244404, 
> region=70236052/-ROOT-
> 2013-11-11 18:04:26,213 INFO 
> org.apache.hadoop.hbase.master.handler.OpenedRegionHandler: Handling OPENED 
> event for -ROOT-,,0.70236052 from HOST-10-18-40-69,60020,1384173244404; 
> deleting unassigned node
> 2013-11-11 18:04:31,553 DEBUG 
> org.apache.hadoop.hbase.master.AssignmentManager: based on AM, current 
> region=-ROOT-,,0.70236052 is on server=null server being checked: 
> HOST-10-18-40-69,60020,1384173244404
> 2013-11-11 18:04:31,561 DEBUG org.apache.hadoop.hbase.master.ServerManager: 
> Added=HOST-10-18-40-69,60020,1384173244404 to dead servers, submitted 
> shutdown handler to be executed, root=false, meta=false
> {code}
> {code}
> 2013-11-11 18:04:32,323 DEBUG 
> org.apache.hadoop.hbase.master.AssignmentManager: The znode of region 
> -ROOT-,,0.70236052 has been deleted.
> 2013-11-11 18:04:32,323 INFO 
> org.apache.hadoop.hbase.master.AssignmentManager: The server is not in online 
> servers, ServerName=HOST-10-18-40-69,60020,1384173244404, region=70236052
> 2013-11-11 18:04:32,323 INFO 
> org.apache.hadoop.hbase.master.AssignmentManager: The master has opened the 
> region -ROOT-,,0.70236052 that was online on 
> HOST-10-18-40-69,60020,1384173244404
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-6205) Support an option to keep data of dropped table for some time

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-6205.
--
Resolution: Later

Resolving for later, We already have the archive and snapshots and we could 
take care of this after HBASE-14439.

> Support an option to keep data of dropped table for some time
> -
>
> Key: HBASE-6205
> URL: https://issues.apache.org/jira/browse/HBASE-6205
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 0.94.0, 0.95.2
>Reporter: chunhui shen
>Assignee: chunhui shen
> Attachments: HBASE-6205.patch, HBASE-6205v2.patch, 
> HBASE-6205v3.patch, HBASE-6205v4.patch, HBASE-6205v5.patch
>
>
> User may drop table accidentally because of error code or other uncertain 
> reasons.
> Unfortunately, it happens in our environment because one user make a mistake 
> between production cluster and testing cluster.
> So, I just give a suggestion, do we need to support an option to keep data of 
> dropped table for some time, e.g. 1 day
> In the patch:
> We make a new dir named .trashtables in the rood dir.
> In the DeleteTableHandler, we move files in dropped table's dir to trash 
> table dir instead of deleting them directly.
> And Create new class TrashCleaner which will clean dropped tables if it is 
> time out with a period check.
> Default keep time for dropped tables is 1 day, and check period is 1 hour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3991) Add Util folder for Utility Scripts

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3991.
--
Resolution: Won't Fix

No progress on this in 5 years. We tend to unify things on the main hbase 
script or the hbase shell, in some cases like the region_mover.rb we ended 
creating better tooling.

> Add Util folder for Utility Scripts
> ---
>
> Key: HBASE-3991
> URL: https://issues.apache.org/jira/browse/HBASE-3991
> Project: HBase
>  Issue Type: Brainstorming
>  Components: scripts, util
>Affects Versions: 0.92.0
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>
> This JIRA is to start discussion around adding some sort of 'util' folder to 
> HBase for common operational scripts.  We're starting to write a lot of HBase 
> analysis utilities that we'd love to share with open source, but don't want 
> to clutter the 'bin' folder, which seems like it should be reserved for 
> start/stop tasks.  If we add a 'util' folder, how do we keep it from becoming 
> a cesspool of half-baked & duplicated operational hacks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3975) NoServerForRegionException stalls write pipeline

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3975.
--
Resolution: Fixed

The new async client is taking care of this.

> NoServerForRegionException stalls write pipeline
> 
>
> Key: HBASE-3975
> URL: https://issues.apache.org/jira/browse/HBASE-3975
> Project: HBase
>  Issue Type: Bug
>  Components: Client
>Affects Versions: 0.89.20100924, 0.90.3, 0.92.0
>Reporter: Nicolas Spiegelberg
>Assignee: Nicolas Spiegelberg
>
> When we process a batch of puts, the current algorithm basically goes like 
> this:
> 1. Find all servers for the Put requests
> 2. Partition Puts by servers
> 3. Make requests
> 4. Collect success/error results
> If we throw an IOE in step 1 or 2, we will abort the whole batch operation.  
> In our case, this was an NoServerForRegionException due to region 
> rebalancing.  However, the asynchronous put case normally has requests going 
> to a wide variety of servers.  We should fail all the put requests that throw 
> an IOE in Step 1 but continue to try all the put requests that succeed at 
> this stage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3854) [thrift] broken thrift examples

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3854.
--
Resolution: Later

Resolving as later for now. We should fix coverage on the hbase-examples 
module. At least the code generation for php, perl and others seems to work.

> [thrift] broken thrift examples
> ---
>
> Key: HBASE-3854
> URL: https://issues.apache.org/jira/browse/HBASE-3854
> Project: HBase
>  Issue Type: Bug
>  Components: Thrift
>Affects Versions: 0.20.0
>Reporter: Alexey Diomin
>Priority: Minor
>
> We introduce NotFound exception in HBASE-1292, but we drop it in HBASE-1367.
> In result:
> 1. incorrect doc in Hbase.thrift in as result in generated java and java-doc
> 2. broken examples in src/examples/thrift/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3792) TableInputFormat leaks ZK connections

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3792.
--
Resolution: Won't Fix

> TableInputFormat leaks ZK connections
> -
>
> Key: HBASE-3792
> URL: https://issues.apache.org/jira/browse/HBASE-3792
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 0.90.1
> Environment: Java 1.6.0_24, Mac OS X 10.6.7
>Reporter: Bryan Keller
> Attachments: patch0.90.4, tableinput.patch
>
>
> The TableInputFormat creates an HTable using a new Configuration object, and 
> it never cleans it up. When running a Mapper, the TableInputFormat is 
> instantiated and the ZK connection is created. While this connection is not 
> explicitly cleaned up, the Mapper process eventually exits and thus the 
> connection is closed. Ideally the TableRecordReader would close the 
> connection in its close() method rather than relying on the process to die 
> for connection cleanup. This is fairly easy to implement by overriding 
> TableRecordReader, and also overriding TableInputFormat to specify the new 
> record reader.
> The leak occurs when the JobClient is initializing and needs to retrieves the 
> splits. To get the splits, it instantiates a TableInputFormat. Doing so 
> creates a ZK connection that is never cleaned up. Unlike the mapper, however, 
> my job client process does not die. Thus the ZK connections accumulate.
> I was able to fix the problem by writing my own TableInputFormat that does 
> not initialize the HTable in the getConf() method and does not have an HTable 
> member variable. Rather, it has a variable for the table name. The HTable is 
> instantiated where needed and then cleaned up. For example, in the 
> getSplits() method, I create the HTable, then close the connection once the 
> splits are retrieved. I also create the HTable when creating the record 
> reader, and I have a record reader that closes the connection when done.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3791) Display total number of zookeeper connections on master.jsp

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3791.
--
Resolution: Fixed

zk.jsp (ZKUtil.dump() see HBASE-2692) from the Master UI already provides the 
total number of connections to ZK open.

> Display total number of zookeeper connections on master.jsp
> ---
>
> Key: HBASE-3791
> URL: https://issues.apache.org/jira/browse/HBASE-3791
> Project: HBase
>  Issue Type: Improvement
>  Components: Zookeeper
>Affects Versions: 0.90.2
>Reporter: Ted Yu
> Attachments: 3791.patch
>
>
> Quite often, user needs to telnet to Zookeeper and type 'stats' to get the 
> connections, or count the connections on zk.jsp
> We should display the total number of connections beside the link to zk.jsp 
> on master.jsp



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3786) Enhance MasterCoprocessorHost to include notification of balancing of each region

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3786.
--
Resolution: Won't Fix

HBASE-4552 was closed and as [~apurtell] stated in HBASE-3529 with NGDATA's 
hbase-indexer we have some indexing functionality that relies on our 
replication infra.

> Enhance MasterCoprocessorHost to include notification of balancing of each 
> region
> -
>
> Key: HBASE-3786
> URL: https://issues.apache.org/jira/browse/HBASE-3786
> Project: HBase
>  Issue Type: Improvement
>  Components: Coprocessors
>Affects Versions: 0.90.2
>Reporter: Ted Yu
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3782) Multi-Family support for bulk upload tools causes File Not Found Exception

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3782.
--
Resolution: Won't Fix

Should be fixed by atomic bulk loading from HBASE-4552

> Multi-Family support for bulk upload tools causes File Not Found Exception
> --
>
> Key: HBASE-3782
> URL: https://issues.apache.org/jira/browse/HBASE-3782
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 0.90.3
>Reporter: Nichole Treadway
> Attachments: HBASE-3782.patch
>
>
> I've been testing HBASE-1861 in 0.90.2, which adds multi-family support for 
> bulk upload tools.
> I found that when running the importtsv program, some reduce tasks fail with 
> a File Not Found exception if there are no keys in the input data which fall 
> into the region assigned to that reduce task.  From what I can determine, it 
> seems that an output directory is created in the write() method and expected 
> to exist in the writeMetaData() method...if there are no keys to be written 
> for that reduce task, the write method is never called and the output 
> directory is never created, but writeMetaData is expecting the output 
> directory to exist...thus the FnF exception:
> 2011-03-17 11:52:48,095 WARN org.apache.hadoop.mapred.TaskTracker: Error 
> running child
> java.io.FileNotFoundException: File does not exist: 
> hdfs://master:9000/awardsData/_temporary/_attempt_201103151859_0066_r_00_0
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:468)
>   at 
> org.apache.hadoop.hbase.regionserver.StoreFile.getUniqueFile(StoreFile.java:580)
>   at 
> org.apache.hadoop.hbase.mapreduce.HFileOutputFormat$1.writeMetaData(HFileOutputFormat.java:186)
>   at 
> org.apache.hadoop.hbase.mapreduce.HFileOutputFormat$1.close(HFileOutputFormat.java:247)
>   at 
> org.apache.hadoop.mapred.ReduceTask.runNewReducer(ReduceTask.java:567)
>   at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:408)
>   at org.apache.hadoop.mapred.Child.main(Child.java:170)
> Simply checking if the file exists should fix the issue. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3778) HBaseAdmin.create doesn't create empty boundary keys

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3778.
--
Resolution: Duplicate

> HBaseAdmin.create doesn't create empty boundary keys
> 
>
> Key: HBASE-3778
> URL: https://issues.apache.org/jira/browse/HBASE-3778
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.90.2
>Reporter: Ted Dunning
> Attachments: HBASE-3778.patch
>
>
> In my ycsb stuff, I have code that looks like this:
> {code}
> String startKey = "user102000";
> String endKey = "user94000";
> admin.createTable(descriptor, startKey.getBytes(), endKey.getBytes(), 
> regions);
> {code}
> The result, however, is a table where the first and last region has defined 
> first and last keys rather than empty keys.
> The patch I am about to attach fixes this, I think.  I have some worries 
> about other uses of Bytes.split, however, and would like some eyes on this 
> patch.  Perhaps we need a new dialect of split.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3725) HBase increments from old value after delete and write to disk

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3725.
--
Resolution: Resolved

Resolving per last comment from [~larsh]

> HBase increments from old value after delete and write to disk
> --
>
> Key: HBASE-3725
> URL: https://issues.apache.org/jira/browse/HBASE-3725
> Project: HBase
>  Issue Type: Bug
>  Components: io, regionserver
>Affects Versions: 0.90.1
>Reporter: Nathaniel Cook
>Assignee: ShiXing
> Attachments: HBASE-3725-0.92-V1.patch, HBASE-3725-0.92-V2.patch, 
> HBASE-3725-0.92-V3.patch, HBASE-3725-0.92-V4.patch, HBASE-3725-0.92-V5.patch, 
> HBASE-3725-0.92-V6.patch, HBASE-3725-Test-v1.patch, HBASE-3725-v3.patch, 
> HBASE-3725.patch
>
>
> Deleted row values are sometimes used for starting points on new increments.
> To reproduce:
> Create a row "r". Set column "x" to some default value.
> Force hbase to write that value to the file system (such as restarting the 
> cluster).
> Delete the row.
> Call table.incrementColumnValue with "some_value"
> Get the row.
> The returned value in the column was incremented from the old value before 
> the row was deleted instead of being initialized to "some_value".
> Code to reproduce:
> {code}
> import java.io.IOException;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.hbase.HBaseConfiguration;
> import org.apache.hadoop.hbase.HColumnDescriptor;
> import org.apache.hadoop.hbase.HTableDescriptor;
> import org.apache.hadoop.hbase.client.Delete;
> import org.apache.hadoop.hbase.client.Get;
> import org.apache.hadoop.hbase.client.HBaseAdmin;
> import org.apache.hadoop.hbase.client.HTableInterface;
> import org.apache.hadoop.hbase.client.HTablePool;
> import org.apache.hadoop.hbase.client.Increment;
> import org.apache.hadoop.hbase.client.Result;
> import org.apache.hadoop.hbase.util.Bytes;
> public class HBaseTestIncrement
> {
>   static String tableName  = "testIncrement";
>   static byte[] infoCF = Bytes.toBytes("info");
>   static byte[] rowKey = Bytes.toBytes("test-rowKey");
>   static byte[] newInc = Bytes.toBytes("new");
>   static byte[] oldInc = Bytes.toBytes("old");
>   /**
>* This code reproduces a bug with increment column values in hbase
>* Usage: First run part one by passing '1' as the first arg
>*Then restart the hbase cluster so it writes everything to disk
>*Run part two by passing '2' as the first arg
>*
>* This will result in the old deleted data being found and used for 
> the increment calls
>*
>* @param args
>* @throws IOException
>*/
>   public static void main(String[] args) throws IOException
>   {
>   if("1".equals(args[0]))
>   partOne();
>   if("2".equals(args[0]))
>   partTwo();
>   if ("both".equals(args[0]))
>   {
>   partOne();
>   partTwo();
>   }
>   }
>   /**
>* Creates a table and increments a column value 10 times by 10 each 
> time.
>* Results in a value of 100 for the column
>*
>* @throws IOException
>*/
>   static void partOne()throws IOException
>   {
>   Configuration conf = HBaseConfiguration.create();
>   HBaseAdmin admin = new HBaseAdmin(conf);
>   HTableDescriptor tableDesc = new HTableDescriptor(tableName);
>   tableDesc.addFamily(new HColumnDescriptor(infoCF));
>   if(admin.tableExists(tableName))
>   {
>   admin.disableTable(tableName);
>   admin.deleteTable(tableName);
>   }
>   admin.createTable(tableDesc);
>   HTablePool pool = new HTablePool(conf, Integer.MAX_VALUE);
>   HTableInterface table = pool.getTable(Bytes.toBytes(tableName));
>   //Increment unitialized column
>   for (int j = 0; j < 10; j++)
>   {
>   table.incrementColumnValue(rowKey, infoCF, oldInc, 
> (long)10);
>   Increment inc = new Increment(rowKey);
>   inc.addColumn(infoCF, newInc, (long)10);
>   tabl

[jira] [Resolved] (HBASE-3432) [hbck] Add "remove table" switch

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3432.
--
Resolution: Won't Fix

closing as stale. Not seen in a long time.

> [hbck] Add "remove table" switch
> 
>
> Key: HBASE-3432
> URL: https://issues.apache.org/jira/browse/HBASE-3432
> Project: HBase
>  Issue Type: New Feature
>  Components: util
>Affects Versions: 0.89.20100924
>Reporter: Lars George
>Priority: Minor
>
> This happened before and I am not sure how the new Master improves on it 
> (this stuff is only available between the lines are buried in some peoples 
> heads - one other thing I wish was for a better place to communicate what 
> each path improves). Just so we do not miss it, there is an issue that 
> sometimes disabling large tables simply times out and the table gets stuck in 
> limbo. 
> From the CDH User list:
> {quote}
> On Fri, Jan 7, 2011 at 1:57 PM, Sean Sechrist <ssechr...@gmail.com> wrote:
> To get them out of META, you can just scan '.META.' for that table name, and 
> delete those rows. We had to do that a few months ago.
> -Sean
> That did it.  For the benefit of others, here's code.  Beware the literal 
> table names, run at your own peril.
> {quote}
> {code}
> import java.io.IOException;
> import org.apache.hadoop.conf.Configuration;
> import org.apache.hadoop.hbase.HBaseConfiguration;
> import org.apache.hadoop.hbase.client.HTable;
> import org.apache.hadoop.hbase.client.Delete;
> import org.apache.hadoop.hbase.client.Result;
> import org.apache.hadoop.hbase.client.MetaScanner;
> import org.apache.hadoop.hbase.util.Bytes;
> public class CleanFromMeta {
> public static class Cleaner implements MetaScanner.MetaScannerVisitor {
> public HTable meta = null;
> public Cleaner(Configuration conf) throws IOException {
> meta = new HTable(conf, ".META.");
> }
> public boolean processRow(Result rowResult) throws IOException {
> String r = new String(rowResult.getRow());
> if (r.startsWith("webtable,")) {
> meta.delete(new Delete(rowResult.getRow()));
> System.out.println("Deleting row " + rowResult);
> }
> return true;
> }
> }
> public static void main(String[] args) throws Exception {
> String tname = ".META.";
> Configuration conf = HBaseConfiguration.create();
> MetaScanner.metaScan(conf, new Cleaner(conf), 
>  Bytes.toBytes("webtable"));
> }
> }
> {code}
> I suggest to move this into HBaseFsck. I do not like personally to have these 
> JRuby scripts floating around that may or may not help. This should be 
> available if a user gets stuck and knows what he is doing (they can delete 
> from .META. anyways). Maybe a "\-\-disable-table  \-\-force" or 
> so? But since disable is already in the shell we could add an "\-\-force" 
> there? Or add a "\-\-delete-table " to the hbck?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-3307) Add checkAndPut to the Thrift API

[Esteban Gutierrez (JIRA)]

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

Esteban Gutierrez resolved HBASE-3307.
--
Resolution: Duplicate

dup of HBASE-10960

> Add checkAndPut to the Thrift API
> -
>
> Key: HBASE-3307
> URL: https://issues.apache.org/jira/browse/HBASE-3307
> Project: HBase
>  Issue Type: Improvement
>  Components: Thrift
>Affects Versions: 0.89.20100924
>Reporter: Chris Tarnas
>Priority: Minor
>  Labels: thrift
>
> It would be very useful to have the checkAndPut method available via the 
> Thrift API. This would both allow for easier atomic updates as well as cut 
> down on at least one Thrift roundtrip for quite a few common tasks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)