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

[Chunhui Shen]

Congratulations, Zheng Hu!


在 2019-08-06 00:54:51，"Xu Cang"  写道：
>Congratulations, Zheng Hu!
>
>On Mon, Aug 5, 2019 at 6:07 AM Guangxu Cheng  wrote:
>
>> Congratulations, Zheng!
>>
>> Allan Yang  于2019年8月5日周一 下午5:13写道：
>>
>> > Congratulations, Hu！
>> > Best Regards
>> > Allan Yang
>> >
>> >
>> > Peter Somogyi  于2019年8月5日周一 下午4:47写道：
>> >
>> > > Congratulations!
>> > >
>> > > On Mon, Aug 5, 2019 at 8:57 AM Pankaj kr  wrote:
>> > >
>> > > > Congratulations Zheng..!!
>> > > >
>> > > > Regards,
>> > > > Pankaj
>> > > >
>> > > > -Original Message-
>> > > > From: Duo Zhang [mailto:zhang...@apache.org]
>> > > > Sent: 05 August 2019 07:38
>> > > > To: HBase Dev List ; hbase-user <
>> > > > u...@hbase.apache.org>
>> > > > Subject: [ANNOUNCE] Please welcome Zheng Hu to the HBase PMC
>> > > >
>> > > > 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:Re: [Announce] 张铎 (Duo Zhang) is Apache HBase PMC chair

[Chunhui Shen]

Thanks Misty  and Congratulations Duo! 
Best Regards,
Chunhui







在 2019-07-23 10:19:58，"Francis Christopher Liu"  写道：
>Thanks a lot Misty!
>
>And congratulations Duo!
>
>Francis
>
>On Sun, Jul 21, 2019 at 8:27 PM Yu Li  wrote:
>
>> Congratulations Duo! And thank you Misty!
>>
>> Best Regards,
>> Yu
>>
>>
>> On Sun, 21 Jul 2019 at 11:21, Allan Yang  wrote:
>>
>> > Congratulations Duo!
>> > Best Regards
>> > Allan Yang
>> >
>> >
>> > 宾莉金（binlijin）  于2019年7月21日周日 上午10:05写道：
>> >
>> > > Congratulations Duo!  and thanks Misty.
>> > >
>> > > Anoop Sam John  于2019年7月21日周日 上午9:26写道：
>> > >
>> > > > Congrats Duo.
>> > > >
>> > > > Thanks Misty for your great work as the PMC chair.
>> > > >
>> > > > Anoop
>> > > >
>> > > > On Sat, Jul 20, 2019 at 12:07 AM Xu Cang  wrote:
>> > > >
>> > > > > Thank you Misty!
>> > > > > Congratulations Duo, thanks for taking extra work!
>> > > > >
>> > > > > On Fri, Jul 19, 2019 at 11:23 AM Zach York <
>> > > zyork.contribut...@gmail.com
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Congratulations Duo! Thanks for offering to take on the
>> additional
>> > > > work!
>> > > > > >
>> > > > > > On Fri, Jul 19, 2019 at 10:34 AM Stack  wrote:
>> > > > > >
>> > > > > > > Thank you Misty for your years of service (FYI, for non-PMCers,
>> > the
>> > > > > > reports
>> > > > > > > Misty wrote to the Apache Board on our behalf were repeatedly
>> > > called
>> > > > > out
>> > > > > > > for their quality and thoughtfulness).
>> > > > > > >
>> > > > > > > Duo Zhang, thank you for taking on the mantle.
>> > > > > > >
>> > > > > > > S
>> > > > > > >
>> > > > > > > On Thu, Jul 18, 2019 at 10:46 AM Misty Linville <
>> > mi...@apache.org>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > > Each Apache project has a project management committee (PMC)
>> > that
>> > > > > > > oversees
>> > > > > > > > governance of the project, votes on new committers and PMC
>> > > members,
>> > > > > and
>> > > > > > > > ensures that the software we produce adheres to the standards
>> > of
>> > > > the
>> > > > > > > > Foundation. One of the roles on the PMC is the PMC chair. The
>> > PMC
>> > > > > chair
>> > > > > > > > represents the project as a Vice President of the Foundation
>> > and
>> > > > > > > > communicates to the board about the project's health, once
>> per
>> > > > > quarter
>> > > > > > > and
>> > > > > > > > at other times as needed.
>> > > > > > > >
>> > > > > > > > It's been my honor to serve as your PMC chair since 2017,
>> when
>> > I
>> > > > took
>> > > > > > > over
>> > > > > > > > from Andrew Purtell. I've decided to step back from my
>> > volunteer
>> > > > ASF
>> > > > > > > > activities to leave room in my life for other things. The
>> HBase
>> > > PMC
>> > > > > > > > nominated Duo for this role, and Duo has kindly agreed! The
>> > board
>> > > > > > passed
>> > > > > > > > this resolution in its meeting yesterday[1] and it is already
>> > > > > > > official[2].
>> > > > > > > > Congratulations, Duo, and thank you for continuing to honor
>> the
>> > > > > project
>> > > > > > > > with your dedication.
>> > > > > > > >
>> > > > > > > > Misty
>> > > > > > > >
>> > > > > > > > [1] The minutes have not yet posted at the time of this
>> email,
>> > > but
>> > > > > will
>> > > > > > > be
>> > > > > > > > available at
>> > > > http://www.apache.org/foundation/records/minutes/2019/.
>> > > > > > > > [2] https://www.apache.org/foundation/#who-runs-the-asf
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > *Best Regards,*
>> > >  lijin bin
>> > >
>> >
>>

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

[Chunhui Shen]

Congratulations, Allan !
At 2018-11-29 00:11:08, "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:Re: [ANNOUNCE] New Committer: Toshihiro Suzuki

[Chunhui Shen]

Congratulations and welcome, Toshihiro!










At 2018-08-02 17:44:58, "Toshihiro Suzuki"  wrote:
>Thank you very much everyone!
>
>
>> On Aug 2, 2018, at 15:26, Nihal Jain  wrote:
>> 
>> Congratulations! :)
>> 
>> On Thu 2 Aug, 2018, 9:49 AM Yu Li,  wrote:
>> 
>>> Congratulations and welcome, Toshihiro!
>>> 
>>> Best Regards,
>>> Yu
>>> 
>>> On 2 August 2018 at 09:35, Pankaj kr  wrote:
>>> 
 Congratulations Toshihiro..!!
 
 
 Thanks & Regards,
 Pankaj Kumar
 Technical Project Leader
 Enterprise Intelligence, IT BU
 
 Huawei Technologies India Pvt. Ltd.
 Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
 Bengaluru-560066, Karnataka
 Tel: + 91-80-49160700 Ext. 71678, Mob: 9535197664,  Email:
 pankaj...@huawei.com
 
 
 __
 This e-mail and its attachments contain confidential information from
 HUAWEI, which
 is intended only for the person or entity whose address is listed above.
 Any use of the
 information contained herein in any way (including, but not limited to,
 total or partial
 disclosure, reproduction, or dissemination) by persons other than the
 intended
 recipient(s) is prohibited. If you receive this e-mail in error, please
 notify the sender by
 phone or email immediately and delete it!
 
 -Original Message-
 From: Josh Elser [mailto:els...@apache.org]
 Sent: Wednesday, August 01, 2018 8:17 PM
 To: dev 
 Subject: [ANNOUNCE] New Committer: Toshihiro Suzuki
 
 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
 
>>> 

Re:Re: [ANNOUNCE] New HBase committer Reid Chan

[Chunhui Shen]

Congratulations Reid!!
在 2018-06-26 18:11:20，"Abhishek Singh Chouhan"  
写道：
>Congrats Reid!!
>
>On Tue, Jun 26, 2018 at 3:17 PM ramkrishna vasudevan <
>ramkrishna.s.vasude...@gmail.com> wrote:
>
>> Congratulations !!!
>>
>> On Tue, Jun 26, 2018 at 3:13 PM Guanghao Zhang  wrote:
>>
>> > Congratulations！
>> >
>> > 2018-06-26 16:50 GMT+08:00 Yu Li :
>> >
>> > > Congratulations and welcome, Reid!
>> > >
>> > > Best Regards,
>> > > Yu
>> > >
>> > > On 26 June 2018 at 15:14, Nihal Jain  wrote:
>> > >
>> > > > Congrats :)
>> > > >
>> > > > On Tue 26 Jun, 2018, 12:22 PM OpenInx,  wrote:
>> > > >
>> > > > > Congratulations and welcome !
>> > > > >
>> > > > > On Tue, Jun 26, 2018 at 2:48 PM, 张铎(Duo Zhang) <
>> > palomino...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > >  Congratulations!
>> > > > > >
>> > > > > > 2018-06-26 14:44 GMT+08:00 Pankaj kr :
>> > > > > >
>> > > > > > > Congratulations Reid Chan..!!
>> > > > > > >
>> > > > > > > Regards,
>> > > > > > > Pankaj Kumar
>> > > > > > > Technical Project Leader
>> > > > > > > Enterprise Intelligence, IT BU
>> > > > > > >
>> > > > > > > Huawei Technologies India Pvt. Ltd.
>> > > > > > > Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
>> > > > > > > Bengaluru-560066, Karnataka
>> > > > > > > Tel: + 91-80-49160700 Ext. 71678, Mob: 9535197664,  Email:
>> > > > > > > pankaj...@huawei.com
>> > > > > > >
>> > > > > > > 
>> > > > > > > __
>> > > > > > > This e-mail and its attachments contain confidential
>> information
>> > > from
>> > > > > > > HUAWEI, which
>> > > > > > > is intended only for the person or entity whose address is
>> listed
>> > > > > above.
>> > > > > > > Any use of the
>> > > > > > > information contained herein in any way (including, but not
>> > limited
>> > > > to,
>> > > > > > > total or partial
>> > > > > > > disclosure, reproduction, or dissemination) by persons other
>> than
>> > > the
>> > > > > > > intended
>> > > > > > > recipient(s) is prohibited. If you receive this e-mail in
>> error,
>> > > > please
>> > > > > > > notify the sender by
>> > > > > > > phone or email immediately and delete it!
>> > > > > > >
>> > > > > > >
>> > > > > > > -Original Message-
>> > > > > > > From: Chia-Ping Tsai [mailto:chia7...@gmail.com]
>> > > > > > > Sent: Tuesday, June 26, 2018 9:59 AM
>> > > > > > > To: dev@hbase.apache.org; 陳浩駿 
>> > > > > > > Subject: [ANNOUNCE] New HBase committer Reid Chan
>> > > > > > >
>> > > > > > > On behalf of the Apache HBase PMC, I am pleased to announce
>> that
>> > > Reid
>> > > > > > Chan
>> > > > > > > has accepted the PMC's invitation to become a committer on the
>> > > > project.
>> > > > > > We
>> > > > > > > appreciate all of Reid’s generous contributions thus far and
>> look
>> > > > > forward
>> > > > > > > to his continued involvement.
>> > > > > > >
>> > > > > > > Congratulations and welcome, Reid!
>> > > > > > >
>> > > > > > > --
>> > > > > > > Chia-Ping
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

Re:Re: [ANNOUNCE] New HBase committer Guangxu Cheng

[Chunhui Shen]

Congratulations!
At 2018-06-04 17:06:20, "Allan Yang"  wrote:
> Congratulations!
>
>Best Regards
>Allan Yang
>
>2018-06-04 16:42 GMT+08:00 Pankaj kr :
>
>> Congratulations Guangxu ..!! :)
>>
>>
>> Pankaj Kumar
>> Technical Project Leader
>> Enterprise Intelligence, IT BU
>>
>> Huawei Technologies India Pvt. Ltd.
>> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
>> Bengaluru-560066, Karnataka
>> Tel: + 91-80-49160700 Ext. 71678, Mob: 9535197664,  Email:
>> pankaj...@huawei.com
>>
>> 
>> __
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which
>> is intended only for the person or entity whose address is listed above.
>> Any use of the
>> information contained herein in any way (including, but not limited to,
>> total or partial
>> disclosure, reproduction, or dissemination) by persons other than the
>> intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender by
>> phone or email immediately and delete it!
>>
>> -Original Message-
>> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
>> Sent: Monday, June 04, 2018 3:00 PM
>> To: HBase Dev List; hbase-user
>> Subject: [ANNOUNCE] New HBase committer Guangxu Cheng
>>
>> On behalf of the Apache HBase PMC, I am pleased to announce that Guangxu
>> Cheng has accepted the PMC's invitation to become a committer on the
>> project. We appreciate all of Guangxu's generous contributions thus far and
>> look forward to his continued involvement.
>>
>> Congratulations and welcome, Guangxu!
>>

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

[Chunhui Shen]

Congrats！


At 2018-03-01 08:29:22, "Esteban Gutierrez"  wrote:
>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:回复：Re: [ANNOUNCE] Please welcome Ashish Singhi to the HBase PMC

[Chunhui Shen]

Congrats！




At 2018-03-01 09:24:47, "岭秀"  wrote:
>Congratulations, Ashish!!  well-deserved
>> > 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:Re: [ANNOUNCE] Please welcome Mike Drob to the HBase PMC

[Chunhui Shen]

Congrats！
At 2018-03-01 07:56:11, "Andrew Purtell"  wrote:
>Congrats 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
>>
>
>
>
>-- 
>Best regards,
>Andrew
>
>Words like orphans lost among the crosstalk, meaning torn from truth's
>decrepit hands
>   - A23, Crosstalk

Re:Re: [ANNOUNCE] New HBase Committer Jan Hentschel

[Chunhui Shen]

Congratulations, Jan !


At 2017-10-27 07:45:25, "Andrew Purtell"  wrote:
>Congratulations and welcome, Jan!
>
>
>On Thu, Oct 26, 2017 at 3:39 PM, Stack  wrote:
>
>> On behalf of the Apache HBase PMC, I am pleased to announce that Jan
>> Hentschel has accepted the PMC's invitation to become a committer on
>> the project.
>>
>> We appreciate all of Jan' great work thus far and look forward to his
>> continued involvement.
>>
>> Please join me in congratulating Jan! (One of us!)
>>
>> S
>>
>
>
>
>-- 
>Best regards,
>Andrew
>
>Words like orphans lost among the crosstalk, meaning torn from truth's
>decrepit hands
>   - A23, Crosstalk

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

[Chunhui Shen]

Congrats Misty!
At 2017-09-22 15:25:18, "Jingcheng Du"  wrote:
>Congratulations, Misty!
>
>2017-09-22 15:10 GMT+08:00 ashish singhi :
>
>> Many Congratulations for the new role, Misty.
>>
>> -Original Message-
>> From: Andrew Purtell [mailto:apurt...@apache.org]
>> Sent: 22 September 2017 00:38
>> 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
>>

Re:Re: [ANNOUNCE] New HBase committer Mike Drob

[Chunhui Shen]

Congrats, Mike!
At 2017-08-02 11:44:12, "Abhishek Singh Chouhan"  
wrote:
>Congratulations Mike!!!
>
>On Wed, Aug 2, 2017 at 9:13 AM Yu Li  wrote:
>
>> Congrats, Mike!
>>
>> Best Regards,
>> Yu
>>
>> On 2 August 2017 at 01:36, Esteban Gutierrez  wrote:
>>
>> > 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:Re: [ANNOUNCE] New HBase committer Vikas Vishwakarma

[Chunhui Shen]

Congrats, Vikas!


At 2017-07-31 16:42:01, "Anoop John"  wrote:
>Congrats Vikas...
>
>On Mon, Jul 31, 2017 at 1:48 PM, Yu Li  wrote:
>> Congratulations, Vikas!
>>
>> Best Regards,
>> Yu
>>
>> On 31 July 2017 at 15:41, Jingcheng Du  wrote:
>>
>>> Congratulations!
>>>
>>> 2017-07-31 14:57 GMT+08:00 Vikas Vishwakarma :
>>>
>>> > Thanks everyone !
>>> >
>>> > On Mon, Jul 31, 2017 at 10:16 AM, Pankaj kr 
>>> wrote:
>>> >
>>> > > Congratulations Vikas..!!
>>> > >
>>> > > Thanks & Regards,
>>> > > Pankaj
>>> > >
>>> > > HUAWEI TECHNOLOGIES CO.LTD.
>>> > > Huawei Tecnologies India Pvt. Ltd.
>>> > > Near EPIP Industrial Area, Kundalahalli Village
>>> > > Whitefield, Bangalore-560066
>>> > > www.huawei.com
>>> > > 
>>> > > -
>>> > > This e-mail and its attachments contain confidential information from
>>> > > HUAWEI, which
>>> > > is intended only for the person or entity whose address is listed
>>> above.
>>> > > Any use of the
>>> > > information contained herein in any way (including, but not limited to,
>>> > > total or partial
>>> > > disclosure, reproduction, or dissemination) by persons other than the
>>> > > intended
>>> > > recipient(s) is prohibited. If you receive this e-mail in error, please
>>> > > notify the sender by
>>> > > phone or email immediately and delete it!
>>> > >
>>> > >
>>> > > -Original Message-
>>> > > From: Andrew Purtell [mailto:apurt...@apache.org]
>>> > > Sent: Saturday, July 29, 2017 6:33 AM
>>> > > To: dev@hbase.apache.org; u...@hbase.apache.org
>>> > > Subject: [ANNOUNCE] New HBase committer Vikas Vishwakarma
>>> > >
>>> > > On behalf of the Apache HBase PMC, I am pleased to announce that Vikas
>>> > > Vishwakarma has accepted the PMC's invitation to become a committer on
>>> > the
>>> > > project.
>>> > >
>>> > > We appreciate all of Vikas's great work thus far and look forward to
>>> > > continued involvement.
>>> > >
>>> > > Please join me in congratulating Vikas!
>>> > >
>>> > > --
>>> > > Best regards,
>>> > > Andrew
>>> > >
>>> >
>>>

Re:Re: [ANNOUNCE] Devaraj Das joins the Apache HBase PMC

[Chunhui Shen]

Congratulations!


At 2017-07-06 09:52:17, "Allan Yang"  wrote:
>Congratulations, Devaraj !
>
>Best Regards
>Allan Yang
>
>2017-07-06 9:44 GMT+08:00 Pankaj kr :
>
>> Congratulations Devaraj..!!
>>
>> Thanks & Regards,
>> Pankaj
>>
>> HUAWEI TECHNOLOGIES CO.LTD.
>> Huawei Tecnologies India Pvt. Ltd.
>> Near EPIP Industrial Area, Kundalahalli Village
>> Whitefield, Bangalore-560066
>> www.huawei.com
>> 
>> -
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which
>> is intended only for the person or entity whose address is listed above.
>> Any use of the
>> information contained herein in any way (including, but not limited to,
>> total or partial
>> disclosure, reproduction, or dissemination) by persons other than the
>> intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender by
>> phone or email immediately and delete it!
>>
>>
>> -Original Message-
>> From: Josh Elser [mailto:els...@apache.org]
>> Sent: Thursday, July 06, 2017 12:27 AM
>> To: dev@hbase.apache.org; u...@hbase.apache.org
>> Subject: [ANNOUNCE] Devaraj Das joins the Apache HBase PMC
>>
>> I'm pleased to announce yet another PMC addition in the form of Devaraj
>> Das. One of the "old guard" in the broader Hadoop umbrella, he's also a
>> long-standing member in our community. We all look forward to the continued
>> contributions and project leadership.
>>
>> Please join me in welcoming Devaraj!
>>
>> - Josh (on behalf of the PMC)
>>

Re:Re: [VOTE] hbase-thirdparty project, first release candidate 1.0.0RC0

[Chunhui Shen]

A small thing, we can't get the real version of the thirdparty  library after 
depend on the new generated hbase-shaded-*.jar.
With the above doubt, I found the file 'META-INF/DEPENDENCIES' which is 
included in hbase-shaded-*.jar,  it contains the information about the shaded 
thirdparty library name and its version.
However,  'META-INF/DEPENDENCIES' of hbase-shaded-protobuf-1.0.0.jar contains 
none...


Just realized such a different point,  it's not a problem for most developers I 
think, but better if we could get the real information about thirdparty library 
in hbase project.

At 2017-07-04 13:42:44, "Yu Li"  wrote:
>bq. In branch-1, relocate all probobuf and guava references?
>Yes sir, IMHO this is nice to have (smile). Thanks.
>
>Best Regards,
>Yu
>
>On 4 July 2017 at 11:41, Stack  wrote:
>
>> On Sun, Jul 2, 2017 at 11:44 PM, Yu Li  wrote:
>> >
>> > bq. No plans to up guava or protobuf versions on branch-1. You think we
>> > should?
>> > We met with guava conflict when using hbase in Flink, and I could see
>> > similar issue mentioned in spark. Since branch-1 is still the stable
>> > release line and will be in the near future, possible to do similar
>> shading
>> > w/o upgrading the guava/protobuf version? Thanks.
>> >
>> > In branch-1, relocate all probobuf and guava references?
>>
>> Thanks Yu Li,
>> S
>>
>>
>> >
>> > Best Regards,
>> > Yu
>> >
>> > On 3 July 2017 at 14:01, 张铎(Duo Zhang)  wrote:
>> >
>> > > Then it will be a bit pain if developers want to see the source code of
>> > the
>> > > relocated classes in IDE?
>> > >
>> > > 2017-07-03 12:31 GMT+08:00 Stack :
>> > >
>> > > > On Sat, Jul 1, 2017 at 8:16 PM, 张铎(Duo Zhang) > >
>> > > > wrote:
>> > > >
>> > > > > +1 (binding)
>> > > > >
>> > > > > Checked sums and signatures: OK
>> > > > > 'mvn clean install': OK, the size of the generated jar files are
>> > > > reasonable
>> > > > > Unzip the generated jar files: OK, all classes are relocated under
>> > > > > org/apache/hadoop/hbase/shaded
>> > > > >
>> > > > > Only one minor question, seems we do not generate sources jars?
>> There
>> > > is
>> > > > > a hbase-shaded-protobuf-1.0.0-sources.jar after 'mvn install' but
>> > the
>> > > > size
>> > > > > is only 22 bytes.
>> > > > >
>> > > > >
>> > > > Good question. This project is a little bit odd. It is just poms
>> (and a
>> > > few
>> > > > patches). The poms do a download, relocation, and then push to deploy
>> > the
>> > > > jars to mvn repo. There is no real 'source' -- not anything that
>> makes
>> > > > sense to stuff in a src.jar --  other than the poms that are here in
>> > the
>> > > > tgz (mvn install puts the jars w/ relocation into your local repo
>> > > add a
>> > > > 'deploy' to push to mvn repository -- see README).
>> > > >
>> > > > Thanks Duo,
>> > > > S
>> > > >
>> > > >
>> > > >
>> > > > > Thanks.
>> > > > >
>> > > > > 2017-07-02 2:38 GMT+08:00 Stack :
>> > > > >
>> > > > > > +1 from me.
>> > > > > > St.Ack
>> > > > > >
>> > > > > > On Fri, Jun 30, 2017 at 3:07 PM, Stack  wrote:
>> > > > > >
>> > > > > > > This is an interesting vote. The vote is on an RC made out of a
>> > new
>> > > > > hbase
>> > > > > > > project, hbase-thirdparty.
>> > > > > > >
>> > > > > > > First the usual stuff.
>> > > > > > >
>> > > > > > > The 1.0.0RC0 is available at:
>> > > > > > >
>> > > > > > >  https://dist.apache.org/repos/dist/dev/hbase/hbase-
>> > > > > thirdparty/1.0.0RC0/
>> > > > > > >
>> > > > > > > Maven artifacts are in the following staging repository:
>> > > > > > >
>> > > > > > >  https://repository.apache.org/content/repositories/
>> > > > > orgapachehbase-1171
>> > > > > > >
>> > > > > > > Artifacts are signed with 8ACC93D2 which is at the tail of our
>> > KEYS
>> > > > > file
>> > > > > > > http://www-us.apache.org/dist/hbase/KEYS.
>> > > > > > >
>> > > > > > > I tagged this RC as 1.0.0RC at 8ffaf3dd561052bcc71772148ecd04
>> > > > > cdf9e224f3
>> > > > > > > in the new hbase-thirdparty repository at [1].
>> > > > > > >
>> > > > > > > Now to the unusual.
>> > > > > > >
>> > > > > > > The artifact was made from a new repository,
>> hbase-thirdparty[1].
>> > > > > > > hbase-thirdparty is a project overseen by the hbase PMC. It
>> came
>> > of
>> > > > > > > discussion on the dev list in the thread '[DISCUSS] More
>> Shading'
>> > > > [2].
>> > > > > > > Its charge is the hosting of ornery thirdparty libs -- e.g.
>> > > protobuf,
>> > > > > > > guava, netty -- that need patching and/or shading so we are no
>> > > longer
>> > > > > > bound
>> > > > > > > by whatever the version of a lib Hadoop happens to ship (and we
>> > can
>> > > > > > change
>> > > > > > > versions w/o damaging out glorious downstreamers). In the past,
>> > > when
>> > > > > > we've
>> > > > > > > been able, we've done this dirty patching and shading work as
>> an
>> > > > > > > unacknowledged 

Re:Re: [ANNOUNCE] New HBase committer Huaxiang Sun

[Chunhui Shen]

Congrats， Huaxiang！






Chunhui

At 2017-06-20 09:21:24, "Guanghao Zhang"  wrote:
>Congratulations and welcome, Huaxiang!
>
>2017-06-20 8:15 GMT+08:00 Jimmy Xiang :
>
>> Congrats!
>>
>> On Mon, Jun 19, 2017 at 5:02 PM, Stephen Jiang 
>> wrote:
>> > Congrats and welcome to the team!
>> >
>> > Stephen
>> >
>> > On Mon, Jun 19, 2017 at 1:43 PM, Mike Drob  wrote:
>> >
>> >> Great work, Huaxiang!
>> >>
>> >> On Mon, Jun 19, 2017 at 2: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:Re: [ANNOUNCE] New Apache HBase committer Ashu Pachauri

[Chunhui Shen]

Congratulations！
At 2017-06-17 11:25:07, "Ashu Pachauri"  wrote:
>Thank you everyone!
>
>Best,
>Ashu Pachauri
>
>On Fri, Jun 16, 2017 at 8:00 PM, Andrew Purtell 
>wrote:
>
>> Congratulations, Ashu!
>>
>> > On Jun 16, 2017, at 4:27 PM, Gary Helmling  wrote:
>> >
>> > On behalf of the Apache HBase PMC, I am pleased to announce that Ashu
>> > Pachauri has accepted the PMC's invitation to become a committer on the
>> > project.  We appreciate all of Ashu's generous contributions thus far and
>> > look forward to his continued involvement.
>> >
>> > Congratulations and welcome, Ashu!
>>

Re:Re: ANNOUNCE: Yu Li joins the Apache HBase PMC

[Chunhui Shen]

Congratulations!

At 2017-04-17 11:50:31, "Phil Yang"  wrote:
>Congratulations!
>
>Thanks,
>Phil
>
>
>2017-04-17 10:31 GMT+08:00 Jingcheng Du :
>
>> Congratulations!!!
>>
>> 2017-04-17 9:53 GMT+08:00 ramkrishna vasudevan <
>> ramkrishna.s.vasude...@gmail.com>:
>>
>> > Congratulations!!
>> >
>> > On Mon, Apr 17, 2017 at 7:05 AM, Guanghao Zhang 
>> > wrote:
>> >
>> > > Congratulations!
>> > >
>> > > 2017-04-16 21:36 GMT+08:00 Yu Li :
>> > >
>> > > > Thanks all! My honor and will do my best.
>> > > >
>> > > > Best Regards,
>> > > > Yu
>> > > >
>> > > > On 16 April 2017 at 14:20, 张铎(Duo Zhang) 
>> > wrote:
>> > > >
>> > > > > Congratulations!
>> > > > >
>> > > > > 2017-04-16 11:24 GMT+08:00 Mikhail Antonov :
>> > > > >
>> > > > >> Congratulations Yu!
>> > > > >>
>> > > > >> -Mikhail
>> > > > >>
>> > > > >> On Sat, Apr 15, 2017 at 12:44 PM, Nick Dimiduk <
>> ndimi...@apache.org
>> > >
>> > > > >> wrote:
>> > > > >>
>> > > > >> > Congratulations Yu and thanks a lot! Keep up the good work!
>> > > > >> >
>> > > > >> > On Fri, Apr 14, 2017 at 7:22 AM Anoop John <
>> anoop.hb...@gmail.com
>> > >
>> > > > >> wrote:
>> > > > >> >
>> > > > >> > > On behalf of the Apache HBase PMC I"m pleased to announce that
>> > Yu
>> > > Li
>> > > > >> > > has accepted our invitation to become a PMC member on the
>> Apache
>> > > > HBase
>> > > > >> > > project. He has been an active contributor to HBase for past
>> > many
>> > > > >> > > years. Looking forward for
>> > > > >> > > many more contributions from him.
>> > > > >> > >
>> > > > >> > > Welcome to the PMC, Yu Li...
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > -Anoop-
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> --
>> > > > >> Thanks,
>> > > > >> Michael Antonov
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

[jira] [Created] (HBASE-11234) FastDiffDeltaEncoder#getFirstKeyInBlock returns wrong result

[chunhui shen (JIRA)]

chunhui shen created HBASE-11234:


 Summary: FastDiffDeltaEncoder#getFirstKeyInBlock returns wrong 
result
 Key: HBASE-11234
 URL: https://issues.apache.org/jira/browse/HBASE-11234
 Project: HBase
  Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen
Priority: Critical
 Fix For: 0.99.0


As Ted found, 
{format}
With this change:

Index: 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestReversibleScanners.java
===
--- 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestReversibleScanners.java
 (revision 1596579)
+++ 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestReversibleScanners.java
 (working copy)
@@ -51,6 +51,7 @@
 import org.apache.hadoop.hbase.filter.FilterList.Operator;
 import org.apache.hadoop.hbase.filter.PageFilter;
 import org.apache.hadoop.hbase.filter.SingleColumnValueFilter;
+import org.apache.hadoop.hbase.io.encoding.DataBlockEncoding;
 import org.apache.hadoop.hbase.io.hfile.CacheConfig;
 import org.apache.hadoop.hbase.io.hfile.HFileContext;
 import org.apache.hadoop.hbase.io.hfile.HFileContextBuilder;
@@ -90,6 +91,7 @@
 CacheConfig cacheConf = new CacheConfig(TEST_UTIL.getConfiguration());
 HFileContextBuilder hcBuilder = new HFileContextBuilder();
 hcBuilder.withBlockSize(2 * 1024);
+hcBuilder.withDataBlockEncoding(DataBlockEncoding.FAST_DIFF);
 HFileContext hFileContext = hcBuilder.build();
 StoreFile.Writer writer = new StoreFile.WriterBuilder(
 TEST_UTIL.getConfiguration(), cacheConf, fs).withOutputDir(

I got:

java.lang.AssertionError: 
expected:testRow0197/testCf:testQual/1400712260004/Put/vlen=13/mvcc=5 but 
was:testRow0198/testCf:testQual/1400712260004/   Put/vlen=13/mvcc=0
  at org.junit.Assert.fail(Assert.java:88)
  at org.junit.Assert.failNotEquals(Assert.java:743)
  at org.junit.Assert.assertEquals(Assert.java:118)
  at org.junit.Assert.assertEquals(Assert.java:144)
  at 
org.apache.hadoop.hbase.regionserver.TestReversibleScanners.seekTestOfReversibleKeyValueScanner(TestReversibleScanners.java:533)
  at 
org.apache.hadoop.hbase.regionserver.TestReversibleScanners.testReversibleStoreFileScanner(TestReversibleScanners.java:108)
{format}


After debugging, it seems the method of FastDiffDeltaEncoder#getFirstKeyInBlock 
become broken. And it will cause hfilescanner#seekBefore returns wrong result.


The solution is simple, see the patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re:Re: Please welcome our newest committer, Mr. Honghua Feng

[Chunhui Shen]

Congrats !!!





At 2014-03-13 10:07:46,haosdent haosd...@gmail.com wrote:
Congratulations!


On Thu, Mar 13, 2014 at 9:59 AM, Rabbit's Foot
rabbitsf...@is-land.com.twwrote:

 Congratulations and welcome!


 2014-03-13 7:59 GMT+08:00 Andrew Purtell apurt...@apache.org:

  Congratulations!
 
 
  On Wed, Mar 12, 2014 at 2:52 PM, Stack st...@duboce.net wrote:
 
   Please welcome our latest committer, 冯宏华.  He has contributed some
 sweet
   patches since he started hanging out in these parts.  Keep up the great
   work Honghua.
  
   St.Ack
  
 
 
 
  --
  Best regards,
 
 - Andy
 
  Problems worthy of attack prove their worth by hitting back. - Piet Hein
  (via Tom White)
 




-- 
Best Regards,
Haosdent Huang

[jira] [Resolved] (HBASE-10214) Regionserver shutdown improperly and leaves the dir in .old not deleted

[chunhui shen (JIRA)]

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

chunhui shen resolved HBASE-10214.
--

  Resolution: Fixed
Hadoop Flags: Reviewed

 Regionserver shutdown improperly and leaves the dir in .old not deleted
 ---

 Key: HBASE-10214
 URL: https://issues.apache.org/jira/browse/HBASE-10214
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.94.14
Reporter: binlijin
 Attachments: HBASE-10214-94-V2.patch, HBASE-10214-94-V3.patch, 
 HBASE-10214-94.patch


 RegionServer log
 {code}
 2013-12-18 15:17:45,771 DEBUG 
 org.apache.hadoop.hbase.regionserver.HRegionServer: Waiting on 
 51b27391410efdca841db264df46085f
 2013-12-18 15:17:45,776 INFO 
 org.apache.hadoop.hbase.regionserver.HRegionServer: Connected to master at 
 null
 2013-12-18 15:17:48,776 INFO 
 org.apache.hadoop.hbase.regionserver.HRegionServer: STOPPED: Exiting; cluster 
 shutdown set and not carrying any regions
 2013-12-18 15:17:48,776 FATAL 
 org.apache.hadoop.hbase.regionserver.HRegionServer: ABORTING region server 
 node,60020,1384410974572: Unhandled exception: null
 java.lang.NullPointerException
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.tryRegionServerReport(HRegionServer.java:880)
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:753)
 at java.lang.Thread.run(Thread.java:662)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re:答复: Please welcome our newest committer, Liang Xie!

[Chunhui Shen]

Congrats and welcome!!




At 2013-12-19 09:20:42,谢良 xieli...@xiaomi.com wrote:
Thanks all for the warm welcomes, this is a great community!
I am looking forward to contributing more with you all !

Best,
Liang

发件人: Todd Lipcon [t...@cloudera.com]
发送时间: 2013年12月19日 8:56
收件人: dev
主题: Re: Please welcome our newest committer, Liang Xie!

Congrats Liang!

-Todd


On Wed, Dec 18, 2013 at 4:53 PM, Ted Yu yuzhih...@gmail.com wrote:

 Congratulations, Liang.

 On Dec 18, 2013, at 4:47 PM, Stack st...@duboce.net wrote:

  谢良 has been doing great work for ages now; we're glad to have him on
 board
  (One of us!).  Keep up the great work 谢良.
 
  St.Ack




--
Todd Lipcon
Software Engineer, Cloudera

Re:Re: [RESULT] ANN: The third hbase-0.96.1 release candidate is available for download

[Chunhui Shen]

About the online merge:


HBCK will report an error now after the online merge,
because the files of merging regions still remain on HDFS which will be cleaned 
by CatalogJanitor later.


In the merge process, we create file references instead of moving files 
together because the latter will break Table Snapshot.
Thus, we couldn't remove these files until the merged region complete 
compaction.


Thanks for the feedback.


I will enhance HBCK to handle this case.















At 2013-12-18 03:21:42,Jean-Marc Spaggiari jean-m...@spaggiari.org wrote:
So. Some feedback.

0.94.x give Status: OK in HBCK.

Did a distcp between the 2 clusters, removed splitlog since I'm not able to
change the owner to my HBase user, did the upgrade, started.

I can see all my tables correctly, able to scan them.

HBCK reports all the tables as okay, even the hbase:meta table, however,
I'm getting this:
ERROR: Empty REGIONINFO_QUALIFIER found in hbase:meta

Ran hbck with -fixEmptyMetaCells
Reran it. All clear now.

Now, I played with the online merge, and I'm still getting errors but they
seems to just be bad timing.

tl;tr; jump to the arrow below.

There is initially 4 regions in the table. I merge the 2 first one
together. That creates a 3 region table. I merge again the 2 first one
together. I wait few minutes, and I run HBCK.

ERROR: Region { meta = null, hdfs =
hdfs://hbasetest1:9000/hbase/data/default/dns/c6569a72cc3c2750d14976ab85f02315,
deployed =  } on HDFS, but not listed in hbase:meta or deployed on any
region server
ERROR: Region { meta = null, hdfs =
hdfs://hbasetest1:9000/hbase/data/default/dns/efa630782e1d603fbc239a11ab292957,
deployed =  } on HDFS, but not listed in hbase:meta or deployed on any
region server

I merged those 4 regions:
merge_region 'bb65f685cdefc4f2491d246f376fc1f0',
'd02ce8e3fa1a200c7f034b349acf8cc8'
merge_region 'efa630782e1d603fbc239a11ab292957',
'c6569a72cc3c2750d14976ab85f02315'

And here is the HDFS content after the merge:
drwxr-xr-x   - hbase hbase  0 2013-12-17 13:35
/hbase/data/default/dns/c6569a72cc3c2750d14976ab85f02315
drwxr-xr-x   - hbase hbase  0 2013-12-17 13:35
/hbase/data/default/dns/d5b74aaa2853b00b0ad0f20f60c74398
drwxr-xr-x   - hbase hbase  0 2013-12-17 13:46
/hbase/data/default/dns/efa630782e1d603fbc239a11ab292957
drwxr-xr-x   - hbase hbase  0 2013-12-17 13:46
/hbase/data/default/dns/f2e0764d4e9dea8bfc0aeed9da3da5f7

And the table in the WebUI:
dns,,1387305985379.f2e0764d4e9dea8bfc0aeed9da3da5f7.
dns,theafronews.ca,1379202071281.d5b74aaa2853b00b0ad0f20f60c74398.

Regions efa630782e1d603fbc239a11ab292957 and
c6569a72cc3c2750d14976ab85f02315 should not be there anymore.

Waiting even longer, they are now removed and hbck reports everything is
correct.

I know there is some people which are running hbck -repair as a cron job.
If that occurs while the regions just got merged, it might re-create the
entries in the meta based on the hdfs content and they will have overlaps
and duplicates

=== So to summarize, seems that merge append pretty quickly, but it waits
for the CatalogJanitor to remove the directories left over by the process.
I think the merge process should remove those files and not rely on the
catalog janitor. I did the test multiple times. First time took about 30
seconds for the janitor to clear the paths. But the 2nd time it took 4
minutes for the janitor to run and to clear the files...

One last small thing. There is no more a split button in the WebUI. When
you don't want to split based on a specific key, it's not trivial that you
have to go into the empty field and press enter.

JM

2013/12/17 Stack st...@duboce.net

 On Tue, Dec 17, 2013 at 7:38 AM, Jean-Marc Spaggiari 
 jean-m...@spaggiari.org wrote:

  Sorry about that mates, I know I'm late. I was fighting against snappy
  codec for the last few days and was not able to correctly startup my
 0.96.1
  version.
 
  So since it's already over, I have done a reduce phase test.
  Verified the signature, checked the documentation and the CHANGES.txt
 file.
  distcp 2TB from a 0.94.x/hadoop 1.0.3 cluster to 0.96.1/hadoop 2.2.0. Ran
  the migration tool.
  online merged an entire table to a single region.
 
 
 Thank you JMS.



  At the end of all of that I have some inconsistencies in the system
  reported by HBCK. (Extra regions, empty regioninfo_qualifier in the meta,
  etc.).
 
 
  I will redo all the steps I did one by one and run HBCK between each to
 see
  where it failed and report what I found. Next step will be to enable
  replication between my 0.94 and my 0.96 clusters.
 

 That'd be really helpful.  Thanks.

 St.Ack

[jira] [Created] (HBASE-10196) Enhance HBCK to understand the case after online region merge

[chunhui shen (JIRA)]

chunhui shen created HBASE-10196:


 Summary: Enhance HBCK to understand the case after online region 
merge
 Key: HBASE-10196
 URL: https://issues.apache.org/jira/browse/HBASE-10196
 Project: HBase
  Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.2, 0.98.1, 0.99.0






--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Created] (HBASE-9810) Global memstore size will be calculated wrongly if replaying recovered edits throws exception

[chunhui shen (JIRA)]

chunhui shen created HBASE-9810:
---

 Summary: Global memstore size will be calculated wrongly if 
replaying recovered edits throws exception
 Key: HBASE-9810
 URL: https://issues.apache.org/jira/browse/HBASE-9810
 Project: HBase
  Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen
Priority: Critical


Recently we encountered such a case in 0.94-version:

Flush is triggered frequently because:

{format}DEBUG org.apache.hadoop.hbase.regionserver.MemStoreFlusher: Flush 
thread woke up because memory above low water=14.4g
{format}

But, the real global memstore size is about 1g.

It seems the global memstore size has been calculated wrongly.


Through the logs, I find the following root cause log:
{format}
ERROR org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler: Failed 
open of region=notifysub2_index,\x83\xDC^\xCD\xA3\x8A\x
E2\x8E\xE6\xAD!\xDC\xE8t\xED,1379148697072.46be7c2d71c555379278a7494df3015e., 
starting to roll back the global memstore size.
java.lang.NegativeArraySizeException
at org.apache.hadoop.hbase.KeyValue.getFamily(KeyValue.java:1096)
at 
org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEdits(HRegion.java:2933)
at 
org.apache.hadoop.hbase.regionserver.HRegion.replayRecoveredEditsIfAny(HRegion.java:2811)
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:583)
at 
org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:499)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3939)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3887)
at 
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:332)
at 
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:108)
at 
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:169)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{format}



Browse the code of this part, seems a critial bug about global memstore size 
when replaying recovered edits.

(RegionServerAccounting#clearRegionReplayEditsSize is called  for each edit 
file, it means the roll back size is smaller than actual when calling 
RegionServerAccounting#rollbackRegionReplayEditsSize)

Anyway,  the solution is easy as the patch.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (HBASE-8980) Assistant Store ----------- An Index Store of HRegion

[chunhui shen (JIRA)]

chunhui shen created HBASE-8980:
---

 Summary: Assistant Store --- An Index Store of HRegion
 Key: HBASE-8980
 URL: https://issues.apache.org/jira/browse/HBASE-8980
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Reporter: chunhui shen
Assignee: chunhui shen


*Background*
a.Generally, we would hope several organizations for the same data. e.g. 
Secondary Index sortes the data from the non-primary key.
b.Now, when we scanning the data on HBase with condition, like ValueFilter, its 
 efficiency seems low
c.We could create an Assistant Store to store the data with another 
organization for the data of HRegion

*Assistant Store*
a.It's a store of HRegion, like HStore, could be created by user through adding 
ColumnFamliy
b.Data in Assistant Store is the copy of data in HRegion, but using another 
organization ,One Exception is that its row could be not in the range of 
HRegion.
For example, 
The region(Range:'row001'~'row999') includes the following KVs in the Store cf:
row001/cf:q1/val001
row002/cf:q1/val002
row003/cf:q1/val003
we could create an Assistant Store(named as) for the region which includes the 
following KVs:
val001/cf:q1/row001
val002/cf:q1/row002
val003/cf:q1/row003

c.We could use local region transaction to ensure the Atomicity and Consistency

*Implementation Dependency*
a.Split the StoreFile as value.(Now,we just split the file as row)
b.Support multi-row transaction in region (Alreadt implemented)

Providing an initial patch on 0.94 version. 
What do you think about such a Store.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8452) Reduce byte copy in PrefixTreeSeeker

[chunhui shen (JIRA)]

chunhui shen created HBASE-8452:
---

 Summary: Reduce byte copy in PrefixTreeSeeker
 Key: HBASE-8452
 URL: https://issues.apache.org/jira/browse/HBASE-8452
 Project: HBase
  Issue Type: Improvement
  Components: regionserver
Affects Versions: 0.95.0
Reporter: chunhui shen
Assignee: chunhui shen


In PrefixTreeSeeker, I think we could do two improvement for deep copy of byte.

1.
{code}
PrefixTreeSeeker#getKeyValue(){
KeyValueUtil.copyToNewKeyValue(ptSearcher.current());
}
{code}
This method will be called frequently when reading. e.g. Scanner#peek(), 
Scanner comparison in KeyValueHeap

2.
{code}
PrefixTreeSeeker#seekToOrBeforeUsingPositionAtOrBefore(){
KeyValue.createKeyValueFromKey(keyOnlyBytes, offset, length);
}
PrefixTreeSeeker#seekToOrBeforeUsingPositionAtOrAfter(){
KeyValue.createKeyValueFromKey(keyOnlyBytes, offset, length);
}
{code}


Solution:
1.Using a cache for seeker's current keyvalue. 
2.Importing new KeyOnlyCell class without coping bytes.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8436) SeekBefore returns wrong result with PREFIX_TREE Encoding

[chunhui shen (JIRA)]

chunhui shen created HBASE-8436:
---

 Summary: SeekBefore returns wrong result with PREFIX_TREE Encoding
 Key: HBASE-8436
 URL: https://issues.apache.org/jira/browse/HBASE-8436
 Project: HBase
  Issue Type: Bug
Reporter: chunhui shen
Assignee: chunhui shen


In SeekBefore case, if we seek the key which is bigger than the last keyvalue
PrefixTreeSeeker#seekToKeyInBlock will not seek correctly.

Make the test case TestPrefixTreeEncoding#testSeekBeforeWithFixedData in the 
patch to show this problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8433) CellComparator#compare is incorrect for faked KeyValue

[chunhui shen (JIRA)]

chunhui shen created HBASE-8433:
---

 Summary: CellComparator#compare is incorrect for faked KeyValue
 Key: HBASE-8433
 URL: https://issues.apache.org/jira/browse/HBASE-8433
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0
Reporter: chunhui shen
Assignee: chunhui shen
Priority: Critical


I found the scan will be in a forever loop when using PREFIX_TREE 
DataBlockEncoding.

And found the root cause is:
CellComparator#compare returns incorrect result for faked KeyValue.

Patch is simple...

Provide a rude test case to verify

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8317) Seek returns wrong result with PREFIX_TREE Encoding

[chunhui shen (JIRA)]

chunhui shen created HBASE-8317:
---

 Summary: Seek returns wrong result with PREFIX_TREE Encoding
 Key: HBASE-8317
 URL: https://issues.apache.org/jira/browse/HBASE-8317
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.0
Reporter: chunhui shen
Assignee: chunhui shen


TestPrefixTreeEncoding#testSeekWithFixedData from the patch could reproduce the 
bug.

An example of the bug case:
Suppose the following rows:

1.row3/c1:q1/
2.row3/c1:q2/
3.row3/c1:q3/
4.row4/c1:q1/
5.row4/c1:q2/

After seeking the row 'row30', the expected peek KV is row4/c1:q1/, but actual 
is row3/c1:q1/.


I just fix this bug case in the patch, 

Maybe we can do more for other potential problems if anyone is familiar with 
the code of PREFIX_TREE



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8287) TestRegionMergeTransactionOnCluster failed in trunk build #4010

[chunhui shen (JIRA)]

chunhui shen created HBASE-8287:
---

 Summary: TestRegionMergeTransactionOnCluster failed in trunk build 
#4010
 Key: HBASE-8287
 URL: https://issues.apache.org/jira/browse/HBASE-8287
 Project: HBase
  Issue Type: Bug
  Components: master
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.95.2, 0.98.0


From the log of trunk build #4010:
{code}
2013-04-04 05:45:59,396 INFO  
[MASTER_TABLE_OPERATIONS-quirinus.apache.org,53514,1365054344859-0] 
handler.DispatchMergingRegionHandler(157): 
Cancel merging regions 
testCleanMergeReference,,1365054353296.bf3d60360122d6c83a246f5f96c2cdd1.,
testCleanMergeReference,testRow0020,1365054353302.72fbc04566e78aa6732531296256a5aa.,
 
because can't move them together after 842ms
 
2013-04-04 05:45:59,396 INFO  [hbase-am-zkevent-worker-pool-2-thread-1] 
master.AssignmentManager$4(1164):
The master has opened the region 
testCleanMergeReference,testRow0020,1365054353302.72fbc04566e78aa6732531296256a5aa.
 that was onlin
e on quirinus.apache.org,45718,1365054345790
{code}

There's a small probability that fail to move merging regions together to same 
regionserver

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-8190) Add documentation of region merges to the book

[chunhui shen (JIRA)]

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

chunhui shen resolved HBASE-8190.
-

  Resolution: Fixed
Hadoop Flags: Reviewed

 Add documentation of region merges to the book
 --

 Key: HBASE-8190
 URL: https://issues.apache.org/jira/browse/HBASE-8190
 Project: HBase
  Issue Type: Sub-task
  Components: documentation
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.98.0

 Attachments: hbase-8190v1.patch, hbase-8190v2.patch, 
 hbase-8190v3.patch


 Add documentation of region merges to the book

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8189) Shell commands of region merge

[chunhui shen (JIRA)]

chunhui shen created HBASE-8189:
---

 Summary: Shell commands of region merge
 Key: HBASE-8189
 URL: https://issues.apache.org/jira/browse/HBASE-8189
 Project: HBase
  Issue Type: Sub-task
  Components: shell
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.98.0


Shell commands of region merge

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8190) Add documentation of region merges to the book

[chunhui shen (JIRA)]

chunhui shen created HBASE-8190:
---

 Summary: Add documentation of region merges to the book
 Key: HBASE-8190
 URL: https://issues.apache.org/jira/browse/HBASE-8190
 Project: HBase
  Issue Type: Sub-task
  Components: documentation
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.98.0


Add documentation of region merges to the book

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-8163) MemstoreChunkPool: An improvement for JAVA GC when using MSLAB

[chunhui shen (JIRA)]

chunhui shen created HBASE-8163:
---

 Summary: MemstoreChunkPool: An improvement for JAVA GC when using 
MSLAB
 Key: HBASE-8163
 URL: https://issues.apache.org/jira/browse/HBASE-8163
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Reporter: chunhui shen
Assignee: chunhui shen


*Background*：
When we use mslab,we will copy the keyvalue together in a structure called 
*Chunk*, therefore we could decrease the heap fragment. 


*Problem*：
When one chunk is full, we will create a new chunk, and then the old chunk will 
be reclaimed by JVM if no reference to it.

Mostly the chunk object would be promoted when doing Young GC, cause increasing 
the cost of YGC 

When a Chunk object has no reference? It should meet two following condition:
1.Memstore which this chunk belongs to is flushed
2.No scanner is opening on the memstore which this chunk belongs to

*solution:*
1.Create a chunk pool to manage the no-reference chunks, instead of being 
reclaimed by JVM
2.When a Chunk has no reference, put it back to the pool
3.The pool has a max capacity, it will skip the chunks when achieve the max size
4.When we need new Chunk to store KeyValue, get it from the pool if exists, 
else create new one by pool, so we could be able to reuse the old chunks

*Test results:*
Environment:
hbase-version:0.94
-Xms4G -Xmx4G -Xmn2G
Row size=50 bytes, Value size=1024 bytes
50 concurrent theads per client, insert 10,000,000 rows

Before:
Avg write request per second:12953
After testing, final result of jstat -gcutil :
YGC YGCT FGC FGCT GCT 
747 36.503 48 2.492 38.995

After:
Avg write request per second:14025
After testing, final result of jstat -gcutil :
YGC YGCT FGC FGCT GCT 
711 20.344 4 0.284 20.628

*improvement: YGC 40+%; WPS 5%+*


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re:Re: review request: HBASE-7403 Online Merge

[Chunhui Shen]

Hey,JM,
 
When regions exist hole or overlap, administrator could merge non adjacent 
regions to keep table consistency,
otherwise we shouldn't merge non adjacent regions. I would point this out in 
the annotation

Thanks for the review

 

Chunhui





At 2013-03-16 20:52:48,Jean-Marc Spaggiari jean-m...@spaggiari.org wrote:
Hi Ted,

I jut gave it a look.

I have updated it on the RB.

Overall, this is very good and I'm eager to see that integrated! I'm
waiting for this feature since the beginning ;)

Regarding non adjacent regions merge? Will the system still be
consistent after that? Or will hbck report some regions overlaps?

JM


2013/3/16 Ted Yu yuzhih...@gmail.com:
 Hi,
 On behalf of Chunhui, I am requesting review for HBASE-7403 Online Merge.

 This JIRA was created 3 months ago.
 Chunhui has responded to review comments very promptly, including a major
 rewrite around the time split transaction was rewritten.

 This feature has widely been requested. I feel the patch is mostly ready to
 go in.
 Here is brief recap of the steps.

 Process of merging two regions:

 a.client sends RPC (dispatch merging regions) to master
 b.master moves the regions together (on the regionserver where the more
 heavily loaded region resided)
 c.master sends RPC (merge regions) to this regionserver
 d.Regionserver executes the region merge transaction in the thread pool

 I think step b is a nice simplification for the problem. In previous
 versions of the patch, the two merging regions stay on respective servers
 which required more complex coordination through zookeeper.

 High level comment as well as detailed review are both welcome.

 Thanks

Re:Re: review request: HBASE-7403 Online Merge

[Chunhui Shen]

Kevin,
Could we repair overlapping regions by hbck now, except offline merge?  I think 
not, if so, please tell me the issue, thanks
 
Regarding non adjacent regions merge,  we will throw the exception as the 
following:
 
+if (!forcible  !HRegionInfo.areAdjacent(regionStateA.getRegion(),
+regionStateB.getRegion())) {
+  throw new ServiceException(Unable to merge not adjacent regions 
+  + regionStateA.getRegion().getRegionNameAsString() + , 
+  + regionStateB.getRegion().getRegionNameAsString()
+  +  where forcible =  + forcible);
+}
 
Using force flag to merge non adjacent regions, I think it's easy to understand 
and could manually merge any two regions if user want. Not only for repairing 
case, also testing case
 
Therefore, I think Ted' thought would limit the freedom of regions merge.
 
Maybe we are worried about the inconsistency if user incorrectly call a force 
regions merge,  I think it is similar with HBaseAdmin#assignRegion possibly 
triggering multi-assign
 
Cheers
Chunhui

At 2013-03-16 21:21:44,Kevin O'dell kevin.od...@cloudera.com wrote:
Ted,

  Why would we use that merge tool when hbck will repair that?  Should we
throw a warning and tell the user to run repair first?
On Mar 16, 2013 9:17 AM, Ted yuzhih...@gmail.com wrote:

 Chunhui replied to this question on review board.

 Basically the force option is to repair overlapping regions or table with
 hole in its regions.

 Personally I think online merge should detect merging regions with hole in
 between them and not require force flag in that case because logically
 they're adjacent.

 Cheers

 On Mar 16, 2013, at 5:52 AM, Jean-Marc Spaggiari jean-m...@spaggiari.org
 wrote:

  Hi Ted,
 
  I jut gave it a look.
 
  I have updated it on the RB.
 
  Overall, this is very good and I'm eager to see that integrated! I'm
  waiting for this feature since the beginning ;)
 
  Regarding non adjacent regions merge? Will the system still be
  consistent after that? Or will hbck report some regions overlaps?
 
  JM
 
 
  2013/3/16 Ted Yu yuzhih...@gmail.com:
  Hi,
  On behalf of Chunhui, I am requesting review for HBASE-7403 Online
 Merge.
 
  This JIRA was created 3 months ago.
  Chunhui has responded to review comments very promptly, including a
 major
  rewrite around the time split transaction was rewritten.
 
  This feature has widely been requested. I feel the patch is mostly
 ready to
  go in.
  Here is brief recap of the steps.
 
  Process of merging two regions:
 
  a.client sends RPC (dispatch merging regions) to master
  b.master moves the regions together (on the regionserver where the more
  heavily loaded region resided)
  c.master sends RPC (merge regions) to this regionserver
  d.Regionserver executes the region merge transaction in the thread pool
 
  I think step b is a nice simplification for the problem. In previous
  versions of the patch, the two merging regions stay on respective
 servers
  which required more complex coordination through zookeeper.
 
  High level comment as well as detailed review are both welcome.
 
  Thanks

[jira] [Created] (HBASE-7887) Support configuring KeyValue Comparator as table

[chunhui shen (JIRA)]

chunhui shen created HBASE-7887:
---

 Summary: Support configuring KeyValue Comparator as table
 Key: HBASE-7887
 URL: https://issues.apache.org/jira/browse/HBASE-7887
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Affects Versions: 0.96.0
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


Now, KeyValue Comparator is static by code in HRegionInfo
{code}
  public KVComparator getComparator() {
return isRootRegion()? KeyValue.ROOT_COMPARATOR: isMetaRegion()?
  KeyValue.META_COMPARATOR: KeyValue.COMPARATOR;
  }
{code}

In some user cases, we need a personalized KeyValue Comparator.
e.g. Current ByteArrayComparator couldn't be used to sort number if exists 
negative number.(Because the bytes of -1 is bigger than the bytes of any other 
number)

I think supporting per-table configuration of KeyValue Comparator would be 
useful.

Welcome comments,
I will make the patch tomorrow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-7887) Support configuring KeyValue Comparator at table level

[chunhui shen (JIRA)]

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

chunhui shen resolved HBASE-7887.
-

   Resolution: Invalid
Fix Version/s: (was: 0.96.0)

 Support configuring KeyValue Comparator at table level
 --

 Key: HBASE-7887
 URL: https://issues.apache.org/jira/browse/HBASE-7887
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Affects Versions: 0.96.0
Reporter: chunhui shen
Assignee: chunhui shen

 Now, KeyValue Comparator is static by code in HRegionInfo
 {code}
   public KVComparator getComparator() {
 return isRootRegion()? KeyValue.ROOT_COMPARATOR: isMetaRegion()?
   KeyValue.META_COMPARATOR: KeyValue.COMPARATOR;
   }
 {code}
 In some user cases, we need a personalized KeyValue Comparator.
 e.g. Current ByteArrayComparator couldn't be used to sort number if exists 
 negative number.(Because the bytes of -1 is bigger than the bytes of any 
 other number)
 I think supporting per-table configuration of KeyValue Comparator would be 
 useful.
 Welcome comments,
 I will make the patch tomorrow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7670) Synchronized operation in CatalogTracker would block handling ZK Event for long time

[chunhui shen (JIRA)]

chunhui shen created HBASE-7670:
---

 Summary: Synchronized operation in CatalogTracker would block 
handling ZK Event for long time
 Key: HBASE-7670
 URL: https://issues.apache.org/jira/browse/HBASE-7670
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.4
Reporter: chunhui shen
Assignee: chunhui shen
Priority: Critical
 Fix For: 0.96.0
 Attachments: HBASE-7670.patch

We found ZK event not be watched by master for a  long time in our testing.
It seems one ZK-Event-Handle thread block it.
Attaching some logs on master
{code}
2013-01-16 22:18:55,667 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: 
Handling transition=RS_ZK_REGION_OPENED, 
2013-01-16 22:18:56,270 DEBUG org.apache.hadoop.hbase.master.AssignmentManager: 
Handling transition=RS_ZK_REGION_OPENED, 
...
2013-01-16 23:55:33,259 INFO org.apache.hadoop.hbase.catalog.CatalogTracker: 
Retrying
org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after 
attempts=100, exceptions:
at 
org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:183)
at org.apache.hadoop.hbase.client.HTable.get(HTable.java:676)
at org.apache.hadoop.hbase.catalog.MetaReader.get(MetaReader.java:247)
at 
org.apache.hadoop.hbase.catalog.MetaReader.getRegion(MetaReader.java:349)
at 
org.apache.hadoop.hbase.catalog.MetaReader.readRegionLocation(MetaReader.java:289)
at 
org.apache.hadoop.hbase.catalog.MetaReader.getMetaRegionLocation(MetaReader.java:276)
at 
org.apache.hadoop.hbase.catalog.CatalogTracker.getMetaServerConnection(CatalogTracker.java:424)
at 
org.apache.hadoop.hbase.catalog.CatalogTracker.waitForMeta(CatalogTracker.java:489)
at 
org.apache.hadoop.hbase.catalog.CatalogTracker.waitForMeta(CatalogTracker.java:451)
at 
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler.process(ServerShutdownHandler.java:289)
at 
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:169)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
2013-01-16 23:55:33,261 WARN org.apache.hadoop.hbase.master.AssignmentManager: 
Attempted to handle region transition for server but server is not online
{code}

Between 2013-01-16 22:18:56 and 2013-01-16 23:55:33, there is no any logs about 
handling ZK Event.


{code}
this.metaNodeTracker = new MetaNodeTracker(zookeeper, throwableAborter) {
  public void nodeDeleted(String path) {
if (!path.equals(node)) return;
ct.resetMetaLocation();
  }
}
public void resetMetaLocation() {
LOG.debug(Current cached META location,  + metaLocation +
  , is not valid, resetting);
synchronized(this.metaAvailable) {
  this.metaAvailable.set(false);
  this.metaAvailable.notifyAll();
}
  }

private AdminProtocol getMetaServerConnection(){
synchronized (metaAvailable){
...
ServerName newLocation = MetaReader.getMetaRegionLocation(this);
...
}
}
{code}

From the above code, we would found that nodeDeleted() would wait synchronized 
(metaAvailable) until MetaReader.getMetaRegionLocation(this) done,
however, getMetaRegionLocation() could be retrying for a long time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7671) Flushing memstore again after last failure could cause data loss

[chunhui shen (JIRA)]

chunhui shen created HBASE-7671:
---

 Summary: Flushing memstore again after last failure could cause 
data loss
 Key: HBASE-7671
 URL: https://issues.apache.org/jira/browse/HBASE-7671
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.4
Reporter: chunhui shen
Assignee: chunhui shen
Priority: Critical
 Fix For: 0.96.0


See the following logs first:
{code}
2013-01-23 18:58:38,801 INFO org.apache.hadoop.hbase.regionserver.Store: 
Flushed , sequenceid=9746535080, memsize=101.8m, into tmp file 
hdfs://dw77.kgb.sqa.cm4:9900/hbase-test3/writetest1/8dc14e35b4d7c0e481e0bb30849cff7d/.tmp/bebeeecc56364b6c8126cf1dc6782a25

2013-01-23 18:58:41,982 WARN org.apache.hadoop.hbase.regionserver.MemStore: 
Snapshot called again without clearing previous. Doing nothing. Another ongoing 
flush or did we fail last attempt?


2013-01-23 18:58:43,274 INFO org.apache.hadoop.hbase.regionserver.Store: 
Flushed , sequenceid=9746599334, memsize=101.8m, into tmp file 
hdfs://dw77.kgb.sqa.cm4:9900/hbase-test3/writetest1/8dc14e35b4d7c0e481e0bb30849cff7d/.tmp/4eede32dc469480bb3d469aaff332313
{code}

The first time memstore flush is failed when commitFile()(Logged the first edit 
above), then trigger server abort, but another flush is coming 
immediately(could caused by move/split,Logged the third edit above) and 
successful.

For the same memstore's snapshot, we get different sequenceid, it causes data 
loss when replaying log edits

See details from the unit test case in the patch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7672) Merging compaction requests in the queue for same store

[chunhui shen (JIRA)]

chunhui shen created HBASE-7672:
---

 Summary: Merging compaction requests in the queue for same store
 Key: HBASE-7672
 URL: https://issues.apache.org/jira/browse/HBASE-7672
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Affects Versions: 0.94.4
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


With a high write presesure, we could found many compaction requests for same 
store in the compaction queue.

I think we could merge compaction requests for same store to increase 
compaction efficiency greately. It is so in 0.90 version because doing 
compacting files selection only when executing compaction

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-7669) ROOT region wouldn't be handled by PRI-IPC-Handler

[chunhui shen (JIRA)]

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

chunhui shen resolved HBASE-7669.
-

  Resolution: Fixed
Hadoop Flags: Reviewed

 ROOT region wouldn't  be handled by PRI-IPC-Handler
 ---

 Key: HBASE-7669
 URL: https://issues.apache.org/jira/browse/HBASE-7669
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.94.4
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0, 0.94.6

 Attachments: 7669-94.patch, HBASE-7669.patch


 RPC reuqest about ROOT region should be handled by PRI-IPC-Handler, just the 
 same as META region

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-7672) Merging compaction requests in the queue for same store

[chunhui shen (JIRA)]

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

chunhui shen resolved HBASE-7672.
-

Resolution: Duplicate

Duplicated as HBASE-5479, move discussion to HBASE-5479

 Merging compaction requests in the queue for same store
 ---

 Key: HBASE-7672
 URL: https://issues.apache.org/jira/browse/HBASE-7672
 Project: HBase
  Issue Type: Improvement
  Components: Compaction
Affects Versions: 0.94.4
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0

 Attachments: HBASE-7672.patch


 With a high write presesure, we could found many compaction requests for same 
 store in the compaction queue.
 I think we could merge compaction requests for same store to increase 
 compaction efficiency greately. It is so in 0.90 version because doing 
 compacting files selection only when executing compaction
 e.g.
 {code}
 SmallCompation active count:1,Queue:
 regionName=abctest,90F9AUIPK4YO47W55WS4R8RSKGDFNRYBNB79COYKHNQD9F62G7,1359104485823.f05568c159940b8a72bd84c988388ad3.,
  storeName=c1, fileCount=4, fileSize=371.1m (212.0m, 53.0m, 53.0m, 53.0m), 
 priority=15, time=56843340270506608
 regionName=abctest,90F9AUIPK4YO47W55WS4R8RSKGDFNRYBNB79COYKHNQD9F62G7,1359104485823.f05568c159940b8a72bd84c988388ad3.,
  storeName=c1, fileCount=4, fileSize=330.4m (171.3m, 53.0m, 53.0m, 53.0m), 
 priority=11, time=56843401092063608
 {code}
 We could merge these two compaction requests

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (HBASE-7299) TestMultiParallel fails intermittently in trunk builds

[chunhui shen (JIRA)]

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

chunhui shen reopened HBASE-7299:
-


TestMultiParallel#testActiveThreadsCount  failed in recent building

From 
https://builds.apache.org/job/PreCommit-HBASE-Build/4051/testReport/junit/org.apache.hadoop.hbase.client/TestMultiParallel/testActiveThreadsCount/

I found one reason:

{code}
testActiveThreadsCount(){
...
table.batch(puts);
ThreadPoolExecutor tExecutor = (ThreadPoolExecutor) poolField.get(table);
assertEquals(slaves, tExecutor.getLargestPoolSize());
...
}
{code}
Here slaves=2,
Though there are 2 live regionservers, if all regions are on one server, there 
will only one pool to execute  table.batch(). So assertEquals(slaves, 
tExecutor.getLargestPoolSize()) is failed.

From the logs, 
{code}
2013-01-16 19:41:15,642 DEBUG [IPC Server handler 2 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1902; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,646 DEBUG [IPC Server handler 4 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1903; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,650 DEBUG [IPC Server handler 0 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1904; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,652 DEBUG [IPC Server handler 1 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1905; 
served=ClientProtocol#multi, queueTime=0, processingTime=1, request=region {
2013-01-16 19:41:15,657 DEBUG [IPC Server handler 3 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1906; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,660 DEBUG [IPC Server handler 2 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1907; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,664 DEBUG [IPC Server handler 4 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1908; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,668 DEBUG [IPC Server handler 0 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1909; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,672 DEBUG [IPC Server handler 1 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1910; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,675 DEBUG [IPC Server handler 3 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1911; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,678 DEBUG [IPC Server handler 2 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1912; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,682 DEBUG [IPC Server handler 4 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1913; 
served=ClientProtocol#multi, queueTime=0, processingTime=1, request=region {
2013-01-16 19:41:15,685 DEBUG [IPC Server handler 0 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1914; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,689 DEBUG [IPC Server handler 1 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1915; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,692 DEBUG [IPC Server handler 3 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1916; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,696 DEBUG [IPC Server handler 2 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1917; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,699 DEBUG [IPC Server handler 4 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1918; 
served=ClientProtocol#multi, queueTime=0, processingTime=2, request=region {
2013-01-16 19:41:15,703 DEBUG [IPC Server handler 0 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1919; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,705 DEBUG [IPC Server handler 1 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1920; 
served=ClientProtocol#multi, queueTime=0, processingTime=1, request=region {
2013-01-16 19:41:15,709 DEBUG [IPC Server handler 3 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1921; 
served=ClientProtocol#multi, queueTime=1, processingTime=1, request=region {
2013-01-16 19:41:15,713 DEBUG [IPC Server handler 2 on 50914] 
ipc.ProtobufRpcServerEngine$Server(209): Call #1922; 
served=ClientProtocol#multi, queueTime=0, processingTime=1, request=region {
2013-01-16 19:41:15,716 DEBUG [IPC Server

[jira] [Created] (HBASE-7529) Wrong ExecutorType for EventType.M_RS_OPEN_ROOT in trunk

[chunhui shen (JIRA)]

chunhui shen created HBASE-7529:
---

 Summary: Wrong ExecutorType for EventType.M_RS_OPEN_ROOT in trunk
 Key: HBASE-7529
 URL: https://issues.apache.org/jira/browse/HBASE-7529
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.96.0
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


{code}
M_RS_OPEN_ROOT(21, ExecutorType.RS_OPEN_REGION),  // Master asking 
RS to open root
{code}

It's a mistake only in trunk, causing ROOT couldn't be online for a long long 
time:

1.ROOT wait open-region-thread to handle opening it.
2.Opening regions wait for ROOT to online, but occupy the threads...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7504) -ROOT- may be offline forever after FullGC of RS

[chunhui shen (JIRA)]

chunhui shen created HBASE-7504:
---

 Summary: -ROOT- may be offline forever after FullGC of  RS
 Key: HBASE-7504
 URL: https://issues.apache.org/jira/browse/HBASE-7504
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen


1.FullGC happen on ROOT regionserver.
2.ZK session timeout, master expire the regionserver and submit to 
ServerShutdownHandler
3.Regionserver complete the FullGC
4.In the process of ServerShutdownHandler, verifyRootRegionLocation returns true
5.ServerShutdownHandler skip assigning -ROOT- region
6.Regionserver abort itself because it reveive YouAreDeadException after a 
regionserver report
7.-ROO- is offline now, and won't be assigned any more unless we restart master



Master Log:
{code}
2012-10-31 19:51:39,043 DEBUG org.apache.hadoop.hbase.master.ServerManager: 
Added=dw88.kgb.sqa.cm4,60020,1351671478752 to dead servers, submitted shutdown 
handler to be executed, root=true, meta=false
2012-10-31 19:51:39,045 INFO 
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler: Splitting logs 
for dw88.kgb.sqa.cm4,60020,1351671478752
2012-10-31 19:51:50,113 INFO 
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler: Server 
dw88.kgb.sqa.cm4,60020,1351671478752 was carrying ROOT. Trying to assign.
2012-10-31 19:52:15,939 DEBUG org.apache.hadoop.hbase.master.ServerManager: 
Server REPORT rejected; currently processing 
dw88.kgb.sqa.cm4,60020,1351671478752 as dead server
2012-10-31 19:52:15,945 INFO 
org.apache.hadoop.hbase.master.handler.ServerShutdownHandler: Skipping log 
splitting for dw88.kgb.sqa.cm4,60020,1351671478752
{code}

No log of assigning -ROOT-

Regionserver log:
{code}
2012-10-31 19:52:15,923 WARN org.apache.hadoop.hbase.util.Sleeper: We slept 
229128ms instead of 10ms, this is likely due to a long garbage collecting 
pause and it's usually bad, see 
http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired
{code}




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7505) Server will hang when stopping cluster, caused by waiting for split threads

[chunhui shen (JIRA)]

chunhui shen created HBASE-7505:
---

 Summary: Server will hang when stopping cluster, caused by waiting 
for split threads
 Key: HBASE-7505
 URL: https://issues.apache.org/jira/browse/HBASE-7505
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


We will retry 100 times (about 3200 minitues) for 
HRegionServer#postOpenDeployTasks now, see 
HConnectionManager#setServerSideHConnectionRetries.

However, 
when we stopping the cluster, we will wait for split threads in  
HRegionServer#join,
if META/ROOT server has already been stopped, the split thread won't exit 
because it is in the retrying for HRegionServer#postOpenDeployTasks


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7506) Judgement of carrtying ROOT/META will become wrong when expiring server

[chunhui shen (JIRA)]

chunhui shen created HBASE-7506:
---

 Summary: Judgement of carrtying ROOT/META will become wrong when 
expiring server
 Key: HBASE-7506
 URL: https://issues.apache.org/jira/browse/HBASE-7506
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


We will check whether server carrying ROOT/META when expiring the server.
See ServerManager#expireServer.

If the dead server carrying META, we assign meta directly in the process of 
ServerShutdownHandler.
If the dead server carrying ROOT, we will offline ROOT and then 
verifyAndAssignRootWithRetries()

How judgement of carrtying ROOT/META become wrong?
If region is in RIT, and isCarryingRegion() return true after addressing from 
zk.
However, once RIT time out(could be caused by this.allRegionServersOffline  
!noRSAvailable, see AssignmentManager#TimeoutMonitor)   and we assign it to 
otherwhere, this judgement become wrong.
See AssignmentManager#isCarryingRegion for details

With the wrong judgement of carrtying ROOT/META, we would assign ROOT/META 
twice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-7507) Make memstore flush be able to retry after exception

[chunhui shen (JIRA)]

chunhui shen created HBASE-7507:
---

 Summary: Make memstore flush be able to retry after exception
 Key: HBASE-7507
 URL: https://issues.apache.org/jira/browse/HBASE-7507
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.3
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0


We will abort regionserver if memstore flush throws exception.

I thinks we could do retry to make regionserver more stable because file system 
may be not ok in a transient time. e.g. Switching namenode in the NamenodeHA 
environment

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira