[jira] [Resolved] (HBASE-17010) Serial replication should handle daughter regions being assigned to another RS

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-17010.
---
   Resolution: Later
Fix Version/s: (was: 1.4.0)
   (was: 2.0.0)

Will reimplement it soon. See HBASE-20046.

> Serial replication should handle daughter regions being assigned to another RS
> --
>
> Key: HBASE-17010
> URL: https://issues.apache.org/jira/browse/HBASE-17010
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Ted Yu
>Assignee: Phil Yang
>Priority: Major
> Attachments: HBASE-17010-branch-1-v1.patch, HBASE-17010-v1.patch, 
> HBASE-17010-v2.patch, HBASE-17010-v3.patch
>
>
> testRegionSplit and testRegionMerge were temporarily disabled by HBASE-16975.
> HBASE-9465 has an assumption that when we split a region, two daughter 
> regions are in same RS with the parent region. But after HBASE-14551 went in, 
> daughter regions may be assigned to other RS directly.  
> This issue is to handle the new behavior and reenable the tests.



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

[jira] [Reopened] (HBASE-17918) document serial replication

[Duo Zhang (JIRA)]

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

Duo Zhang reopened HBASE-17918:
---

> document serial replication
> ---
>
> Key: HBASE-17918
> URL: https://issues.apache.org/jira/browse/HBASE-17918
> Project: HBase
>  Issue Type: Task
>  Components: documentation, Replication
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Sean Busbey
>Assignee: Yi Mei
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-beta-1
>
> Attachments: HBASE-17918.v1.patch, HBASE-17918.v2.patch, 
> HBASE-17918.v3.patch
>
>
> It looks like HBASE-9465 addresses one of the major flaws in our existing 
> replication (namely that order of delivery is not assured). All I see in the 
> reference guide is a note on {{hbase.serial.replication.waitingMs}}. Instead 
> we should cover this in the replication section, especially given that we 
> call out the order of delivery limitation.



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

[jira] [Reopened] (HBASE-17010) Serial replication should handle daughter regions being assigned to another RS

[Duo Zhang (JIRA)]

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

Duo Zhang reopened HBASE-17010:
---

> Serial replication should handle daughter regions being assigned to another RS
> --
>
> Key: HBASE-17010
> URL: https://issues.apache.org/jira/browse/HBASE-17010
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Ted Yu
>Assignee: Phil Yang
>Priority: Major
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17010-branch-1-v1.patch, HBASE-17010-v1.patch, 
> HBASE-17010-v2.patch, HBASE-17010-v3.patch
>
>
> testRegionSplit and testRegionMerge were temporarily disabled by HBASE-16975.
> HBASE-9465 has an assumption that when we split a region, two daughter 
> regions are in same RS with the parent region. But after HBASE-14551 went in, 
> daughter regions may be assigned to other RS directly.  
> This issue is to handle the new behavior and reenable the tests.



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

[jira] [Resolved] (HBASE-9465) Push entries to peer clusters serially

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-9465.
--
   Resolution: Later
Fix Version/s: (was: 1.5.0)
   (was: 2.0.0)

Will reimplement it soon. See HBASE-20046.

> Push entries to peer clusters serially
> --
>
> Key: HBASE-9465
> URL: https://issues.apache.org/jira/browse/HBASE-9465
> Project: HBase
>  Issue Type: New Feature
>  Components: regionserver, Replication
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Honghua Feng
>Assignee: Phil Yang
>Priority: Critical
> Attachments: HBASE-20048-v2.patch, HBASE-9465-branch-1-v1.patch, 
> HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, 
> HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, 
> HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, 
> HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, 
> HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, 
> HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, 
> HBASE-9465-v7.patch, HBASE-9465.pdf
>
>
> When region-move or RS failure occurs in master cluster, the hlog entries 
> that are not pushed before region-move or RS-failure will be pushed by 
> original RS(for region move) or another RS which takes over the remained hlog 
> of dead RS(for RS failure), and the new entries for the same region(s) will 
> be pushed by the RS which now serves the region(s), but they push the hlog 
> entries of a same region concurrently without coordination.
> This treatment can possibly lead to data inconsistency between master and 
> peer clusters:
> 1. there are put and then delete written to master cluster
> 2. due to region-move / RS-failure, they are pushed by different 
> replication-source threads to peer cluster
> 3. if delete is pushed to peer cluster before put, and flush and 
> major-compact occurs in peer cluster before put is pushed to peer cluster, 
> the delete is collected and the put remains in peer cluster
> In this scenario, the put remains in peer cluster, but in master cluster the 
> put is masked by the delete, hence data inconsistency between master and peer 
> clusters



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

[jira] [Reopened] (HBASE-9465) Push entries to peer clusters serially

[Duo Zhang (JIRA)]

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

Duo Zhang reopened HBASE-9465:
--

> Push entries to peer clusters serially
> --
>
> Key: HBASE-9465
> URL: https://issues.apache.org/jira/browse/HBASE-9465
> Project: HBase
>  Issue Type: New Feature
>  Components: regionserver, Replication
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Honghua Feng
>Assignee: Phil Yang
>Priority: Critical
> Fix For: 2.0.0, 1.5.0
>
> Attachments: HBASE-20048-v2.patch, HBASE-9465-branch-1-v1.patch, 
> HBASE-9465-branch-1-v1.patch, HBASE-9465-branch-1-v2.patch, 
> HBASE-9465-branch-1-v3.patch, HBASE-9465-branch-1-v4.patch, 
> HBASE-9465-branch-1-v4.patch, HBASE-9465-branch-1.v4.revert.patch, 
> HBASE-9465-v1.patch, HBASE-9465-v2.patch, HBASE-9465-v2.patch, 
> HBASE-9465-v3.patch, HBASE-9465-v4.patch, HBASE-9465-v5.patch, 
> HBASE-9465-v6.patch, HBASE-9465-v6.patch, HBASE-9465-v7.patch, 
> HBASE-9465-v7.patch, HBASE-9465.pdf
>
>
> When region-move or RS failure occurs in master cluster, the hlog entries 
> that are not pushed before region-move or RS-failure will be pushed by 
> original RS(for region move) or another RS which takes over the remained hlog 
> of dead RS(for RS failure), and the new entries for the same region(s) will 
> be pushed by the RS which now serves the region(s), but they push the hlog 
> entries of a same region concurrently without coordination.
> This treatment can possibly lead to data inconsistency between master and 
> peer clusters:
> 1. there are put and then delete written to master cluster
> 2. due to region-move / RS-failure, they are pushed by different 
> replication-source threads to peer cluster
> 3. if delete is pushed to peer cluster before put, and flush and 
> major-compact occurs in peer cluster before put is pushed to peer cluster, 
> the delete is collected and the put remains in peer cluster
> In this scenario, the put remains in peer cluster, but in master cluster the 
> put is masked by the delete, hence data inconsistency between master and peer 
> clusters



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

RE: [ANNOUNCE] New HBase committer Peter Somogyi

[Pankaj kr]

Congratulations Peter..!! :) 

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: Sean Busbey [mailto:bus...@apache.org] 
Sent: Friday, February 23, 2018 3:09 AM
To: dev; u...@hbase.apache.org
Cc: psomo...@apache.org
Subject: [ANNOUNCE] New HBase committer Peter Somogyi

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] [Reopened] (HBASE-19400) Add missing security checks in MasterRpcServices

[Appy (JIRA)]

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

Appy reopened HBASE-19400:
--

Uploading patch for branch-1
Patch is both for this jira and few lines in HBASE-19401

> Add missing security checks in MasterRpcServices
> 
>
> Key: HBASE-19400
> URL: https://issues.apache.org/jira/browse/HBASE-19400
> Project: HBase
>  Issue Type: Sub-task
>Affects Versions: 2.0.0-beta-1
>Reporter: Balazs Meszaros
>Assignee: Appy
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19400.branch-1.001.patch, 
> HBASE-19400.master.001.patch, HBASE-19400.master.002.patch, 
> HBASE-19400.master.003.patch, HBASE-19400.master.004.patch, 
> HBASE-19400.master.004.patch, HBASE-19400.master.005.patch, 
> HBASE-19400.master.006.patch, HBASE-19400.master.007.patch, 
> HBASE-19400.master.007.patch
>
>
> The following RPC methods in MasterRpcServices do not have ACL check for 
> ADMIN rights.
> - normalize
> - setNormalizerRunning
> - runCatalogScan
> - enableCatalogJanitor
> - runCleanerChore
> - setCleanerChoreRunning
> - execMasterService
> - execProcedure
> - execProcedureWithRet



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

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[OpenInx]

Congratulations, Peter.

On Fri, Feb 23, 2018 at 7:46 AM, Jerry He  wrote:

>  Congrats, Peter!
>
> On Thu, Feb 22, 2018 at 2:53 PM, Andrew Purtell 
> wrote:
>
> > Congratulations and welcome, 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!
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>



-- 
==
Openinx  blog : http://openinx.github.io

TO BE A GREAT HACKER !
==

Re: Critical security related notice for releases containing HBASE-19483 (1.4.1, 1.5.0, 2.0.0)

[Ted Yu]

bq. only the clusters which need authorization should set this config as
false

Looks like a typo above : 'as true'

Cheers

On Thu, Feb 22, 2018 at 4:01 PM, Apekshit Sharma  wrote:

> Default value for hbase.security.authorization has been changed from true
> to false. Secured clusters should make sure to explicitly set it to true in
> XML configuration file before upgrading to one of these versions. (
> https://issues.apache.org/jira/browse/HBASE-19483)
>
> True as default value of hbase.security.authorization doesn't make any
> sense, since not all clusters need authorization. (History: HBASE-13275
> ) Rather, only the
> clusters which need authorization should set this config as false. Going
> further, setting this config should be single switch to enable/disable
> authorization, conditional on appropriate coprocessors loaded (a condition
> we'll try to remove in future by incorporating access control directly into
> hbase as core feature rather then as coprocessor).
>
> -- Appy
>

Re: Critical security related notice for releases containing HBASE-19483 (1.4.1, 1.5.0, 2.0.0)

[Misty Stanley-Jones]

Thanks, Appy. Big thanks for making sure this change was documented during
the patch review, as well! It seems maybe this notice should have gone to
the users@ list, as well.

On Thu, Feb 22, 2018 at 4:02 PM Apekshit Sharma  wrote:

> Default value for hbase.security.authorization has been changed from true
> to false. Secured clusters should make sure to explicitly set it to true in
> XML configuration file before upgrading to one of these versions. (
> https://issues.apache.org/jira/browse/HBASE-19483)
>
> True as default value of hbase.security.authorization doesn't make any
> sense, since not all clusters need authorization. (History: HBASE-13275
> ) Rather, only the
> clusters which need authorization should set this config as false. Going
> further, setting this config should be single switch to enable/disable
> authorization, conditional on appropriate coprocessors loaded (a condition
> we'll try to remove in future by incorporating access control directly into
> hbase as core feature rather then as coprocessor).
>
> -- Appy
>

[jira] [Created] (HBASE-20055) Remove declaration of un-thrown exceptions and unused setRegionStateBackToOpen() from MergeTableRegionsProcedure

[Umesh Agashe (JIRA)]

Umesh Agashe created HBASE-20055:


 Summary: Remove declaration of un-thrown exceptions and unused 
setRegionStateBackToOpen() from MergeTableRegionsProcedure
 Key: HBASE-20055
 URL: https://issues.apache.org/jira/browse/HBASE-20055
 Project: HBase
  Issue Type: Improvement
  Components: amv2
Affects Versions: 2.0.0-beta-1
Reporter: Umesh Agashe
Assignee: Umesh Agashe
 Fix For: 2.0.0-beta-2


A few methods declare exceptions in throws statement that are not thrown and 
method setRegionStateBackToOpen() is not used in MergeTableRegionsProcedure.



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

Critical security related notice for releases containing HBASE-19483 (1.4.1, 1.5.0, 2.0.0)

[Apekshit Sharma]

Default value for hbase.security.authorization has been changed from true
to false. Secured clusters should make sure to explicitly set it to true in
XML configuration file before upgrading to one of these versions. (
https://issues.apache.org/jira/browse/HBASE-19483)

True as default value of hbase.security.authorization doesn't make any
sense, since not all clusters need authorization. (History: HBASE-13275
) Rather, only the
clusters which need authorization should set this config as false. Going
further, setting this config should be single switch to enable/disable
authorization, conditional on appropriate coprocessors loaded (a condition
we'll try to remove in future by incorporating access control directly into
hbase as core feature rather then as coprocessor).

-- Appy

Re: [VOTE] The second HBase 1.4.2 release candidate (RC1) is available

[Andrew Purtell]

The close date will be *Wednesday* February 28, 2018.

On Thu, Feb 22, 2018 at 3:55 PM, Andrew Purtell  wrote:

> The second HBase 1.4.2 release candidate (RC1) is available for download
> at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/ and Maven
> artifacts are available in the temporary repository
> https://repository.apache.org/content/repositories/orgapachehbase-1196/ .
>
> The git tag corresponding to the candidate is '1.4.2RC1' (b4ec89059c).
> Note this is different from branch-1.4 by one commit because we had an
> intervening commit between tag and push (08b9939974, HBASE-20016) while I
> was running tests. The only difference is the CHANGES.txt update for
> 1.4.2RC1 is placed ahead of the commit for HBASE-20016, but does not
> mention it, which is fine, because 1.4.2RC1 does not contain HBASE-20016.
>
> A detailed source and binary compatibility report for this release is
> available for your review at https://dist.apache.org/repos/
> dist/dev/hbase/hbase-1.4.2RC1/compat-check-report.html .
>
> A list of the 22 issues resolved in this release can be found at
> https://s.apache.org/aGcb .
>
> Please try out the candidate and vote +1/0/-1.
>
> This vote will be open for at least 72 hours. Unless objection I will try
> to close it Thursday February 28, 2018 if we have sufficient votes.
>
> Prior to making this announcement I made the following preflight checks:
>
>- RAT check passes (7u80)
>- Unit test suite passes (8u131)
>- LTT load 1M rows with 100% verification and 20% updates (8u131)
>- PE sequentialWrite, sequentialRead, randomWrite, randomRead,
>scanRange100 (8u131)
>- ITBLL Loop 1 100M rows (8u131)
>
>
>
> --
> Best regards,
> Andrew
>
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

[VOTE] The second HBase 1.4.2 release candidate (RC1) is available

[Andrew Purtell]

The second HBase 1.4.2 release candidate (RC1) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/ and Maven
artifacts are available in the temporary repository
https://repository.apache.org/content/repositories/orgapachehbase-1196/ .

The git tag corresponding to the candidate is '1.4.2RC1' (b4ec89059c). Note
this is different from branch-1.4 by one commit because we had an
intervening commit between tag and push (08b9939974, HBASE-20016) while I
was running tests. The only difference is the CHANGES.txt update for
1.4.2RC1 is placed ahead of the commit for HBASE-20016, but does not
mention it, which is fine, because 1.4.2RC1 does not contain HBASE-20016.

A detailed source and binary compatibility report for this release is
available for your review at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.2RC1/compat-check-report.html
.

A list of the 22 issues resolved in this release can be found at
https://s.apache.org/aGcb .

Please try out the candidate and vote +1/0/-1.

This vote will be open for at least 72 hours. Unless objection I will try
to close it Thursday February 28, 2018 if we have sufficient votes.

Prior to making this announcement I made the following preflight checks:

   - RAT check passes (7u80)
   - Unit test suite passes (8u131)
   - LTT load 1M rows with 100% verification and 20% updates (8u131)
   - PE sequentialWrite, sequentialRead, randomWrite, randomRead,
   scanRange100 (8u131)
   - ITBLL Loop 1 100M rows (8u131)



-- 
Best regards,
Andrew

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Jerry He]

 Congrats, Peter!

On Thu, Feb 22, 2018 at 2:53 PM, Andrew Purtell  wrote:

> Congratulations and welcome, 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!
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Andrew Purtell]

Congratulations and welcome, 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!
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Chia-Ping Tsai]

Congratulations, Peter

On 2018/02/22 19:08:37, 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!
> 

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Yu Li]

Congratulations Peter!

Best Regards,
Yu

On 22 February 2018 at 20:51, Huaxiang Sun  wrote:

> Congratulations Peter!
>
>
> > On Feb 22, 2018, at 11:50 AM, Umesh Agashe  wrote:
> >
> > Congratulations Peter!
> >
> > On Thu, Feb 22, 2018 at 11:12 AM, Esteban Gutierrez <
> este...@cloudera.com>
> > wrote:
> >
> >> 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-20054) Forward port HBASE-18282 ReplicationLogCleaner can delete WALs not yet replicated in case of KeeperException

[Ted Yu (JIRA)]

Ted Yu created HBASE-20054:
--

 Summary: Forward port HBASE-18282 ReplicationLogCleaner can delete 
WALs not yet replicated in case of KeeperException
 Key: HBASE-20054
 URL: https://issues.apache.org/jira/browse/HBASE-20054
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 3.0.0
 Attachments: 20054.v1.txt

Some changes from HBASE-18282 were missing in master branch:

* The retry in ReplicationSourceManager#adoptAbandonedQueues
*  new tests in TestLogsCleaner

This issue is to forward port the above to master branch



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

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Huaxiang Sun]

Congratulations Peter!


> On Feb 22, 2018, at 11:50 AM, Umesh Agashe  wrote:
> 
> Congratulations Peter!
> 
> On Thu, Feb 22, 2018 at 11:12 AM, Esteban Gutierrez 
> wrote:
> 
>> 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!
 
>>> 
>> 

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Umesh Agashe]

Congratulations Peter!

On Thu, Feb 22, 2018 at 11:12 AM, Esteban Gutierrez 
wrote:

> 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-20053) Remove .cmake file extension from .gitignore

[Ted Yu (JIRA)]

Ted Yu created HBASE-20053:
--

 Summary: Remove .cmake file extension from .gitignore
 Key: HBASE-20053
 URL: https://issues.apache.org/jira/browse/HBASE-20053
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu


There are .cmake files under hbase-native-client/cmake/ which are under source 
control.

The .cmake extension should be taken out of hbase-native-client/.gitignore



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

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!
> >
>

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Ted Yu]

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!
>

Re: [ANNOUNCE] New HBase committer Peter Somogyi

[Alexander Leblang]

Congrats Peter!

On Thu, Feb 22, 2018 at 2:08 PM, 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!
>

[ANNOUNCE] New HBase committer Peter Somogyi

[Sean Busbey]

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] [Resolved] (HBASE-20042) TestRegionServerAbort flakey

[stack (JIRA)]

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

stack resolved HBASE-20042.
---
Resolution: Fixed
  Assignee: stack

Resolving. No longer on flakies list.

> TestRegionServerAbort flakey
> 
>
> Key: HBASE-20042
> URL: https://issues.apache.org/jira/browse/HBASE-20042
> Project: HBase
>  Issue Type: Sub-task
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: 
> 0001-HBASE-20042-TestRegionServerAbort-flakey-ADDENDUM-RE.patch, 
> HBASE-20042.branch-2.001.patch
>
>
> Failed with a hang and an index out of bounds in last 30 runs. The timeout 
> has no logs. The indexoutofbounds seems basic... Looking at logs all seems to 
> be working... eventually... as it should.



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

[jira] [Resolved] (HBASE-20044) TestClientClusterStatus is flakey

[stack (JIRA)]

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

stack resolved HBASE-20044.
---
Resolution: Fixed
  Assignee: stack

Resolving. No longer on flakies list.

> TestClientClusterStatus is flakey
> -
>
> Key: HBASE-20044
> URL: https://issues.apache.org/jira/browse/HBASE-20044
> Project: HBase
>  Issue Type: Sub-task
>  Components: flakey
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20044.branch-2.001.patch
>
>
> It killed a nightly. Failed in flakey suite.  The compare is too sensitive to 
> slightest variance. Here are two failiures... one because the previous test 
> had not finished putting back a Region that had been offlined, and the other 
> because the count of requests was off slightly. Let me make the compare 
> coarser 
> {code}
> Test set: org.apache.hadoop.hbase.TestClientClusterStatus
> ---
> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 27.858 s <<< 
> FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> testNone(org.apache.hadoop.hbase.TestClientClusterStatus)  Time elapsed: 
> 0.236 s  <<< FAILURE!
> java.lang.AssertionError: 
> expected: Number of backup masters: 2
>   asf903.gq1.ygridcore.net,34661,1519246530655
>   asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
>   asf903.gq1.ygridcore.net,37432,1519246533632
>   asf903.gq1.ygridcore.net,42964,1519246533554
>   asf903.gq1.ygridcore.net,43699,1519246533376
>   asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
>   asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.25
> Number of requests: 17
> Number of regions: 1
> Number of regions in transition: 0> but was: asf903.gq1.ygridcore.net,45687,1519246533030
> Number of backup masters: 2
>   asf903.gq1.ygridcore.net,34661,1519246530655
>   asf903.gq1.ygridcore.net,34734,1519246533133
> Number of live region servers: 4
>   asf903.gq1.ygridcore.net,37432,1519246533632
>   asf903.gq1.ygridcore.net,42964,1519246533554
>   asf903.gq1.ygridcore.net,43699,1519246533376
>   asf903.gq1.ygridcore.net,56911,1519246533711
> Number of dead region servers: 1
>   asf903.gq1.ygridcore.net,57278,1519246533770
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0>
>   at 
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}
> and 
> {code}
> [ERROR] Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.416 
> s <<< FAILURE! - in org.apache.hadoop.hbase.TestClientClusterStatus
> [ERROR] testNone(org.apache.hadoop.hbase.TestClientClusterStatus)  Time 
> elapsed: 0.065 s  <<< FAILURE!
> java.lang.AssertionError: 
> expected: Number of backup masters: 2
>   9845c79afe69,35076,1519227086213
>   9845c79afe69,45963,1519227086363
> Number of live region servers: 4
>   9845c79afe69,34709,1519227086571
>   9845c79afe69,34961,1519227086645
>   9845c79afe69,35891,1519227086720
>   9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
>   9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 17
> Number of regions: 2
> Number of regions in transition: 0> but was: 9845c79afe69,46509,1519227084385
> Number of backup masters: 2
>   9845c79afe69,35076,1519227086213
>   9845c79afe69,45963,1519227086363
> Number of live region servers: 4
>   9845c79afe69,34709,1519227086571
>   9845c79afe69,34961,1519227086645
>   9845c79afe69,35891,1519227086720
>   9845c79afe69,36139,1519227086486
> Number of dead region servers: 1
>   9845c79afe69,41992,1519227086820
> Average load: 0.5
> Number of requests: 19
> Number of regions: 2
> Number of regions in transition: 0>
>   at 
> org.apache.hadoop.hbase.TestClientClusterStatus.testNone(TestClientClusterStatus.java:107)
> {code}



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

[jira] [Resolved] (HBASE-19554) AbstractTestDLS.testThreeRSAbort sometimes fails in pre commit

[stack (JIRA)]

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

stack resolved HBASE-19554.
---
  Resolution: Fixed
Hadoop Flags: Reviewed

All subtasks resolved. This family of tests no longer shows on the flakies 
list. Nice work [~Apache9]

> AbstractTestDLS.testThreeRSAbort sometimes fails in pre commit
> --
>
> Key: HBASE-19554
> URL: https://issues.apache.org/jira/browse/HBASE-19554
> Project: HBase
>  Issue Type: Sub-task
>  Components: Recovery, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19554-thread-dump.patch, HBASE-19554.patch
>
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/10554/artifact/patchprocess/patch-unit-hbase-server.txt
> The error message is a bit strange:
> {quote}
> [ERROR] testThreeRSAbort(org.apache.hadoop.hbase.master.TestDLSAsyncFSWAL) 
> Time elapsed: 20.627 s <<< ERROR!
> org.apache.hadoop.hbase.TableNotFoundException: Region of 
> 'hbase:namespace,,1513320505933.451650152885a3b41d0b1110deca513c.' is 
> expected in the table of 'testThreeRSAbort', but hbase:meta says it is in the 
> table of 'hbase:namespace'. hbase:meta might be damaged.
> {quote}
> It fails for both FSHLog and AsyncFSWAL. Need to dig more.



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

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

[stack (JIRA)]

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

stack resolved HBASE-19391.
---
Resolution: Fixed

Pushed addendum.

> 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
>Affects Versions: 2.0.0-alpha-4, 1.4.2
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Major
> Fix For: 1.5.0, 2.0.0-beta-2
>
> Attachments: 
> 0001-HBASE-19391-Calling-HRegion-initializeRegionInternal.patch, 
> HBASE-19391.master.v0.patch
>
>
> 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
(v7.6.3#76005)

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

[stack (JIRA)]

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

stack reopened HBASE-19391:
---

Reopened to push an addendum.

> 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
>Affects Versions: 2.0.0-alpha-4, 1.4.2
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Major
> Fix For: 1.5.0, 2.0.0-beta-2
>
> Attachments: 
> 0001-HBASE-19391-Calling-HRegion-initializeRegionInternal.patch, 
> HBASE-19391.master.v0.patch
>
>
> 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
(v7.6.3#76005)

[jira] [Created] (HBASE-20052) TestRegionOpen#testNonExistentRegionReplica fails due to NPE

[Ted Yu (JIRA)]

Ted Yu created HBASE-20052:
--

 Summary: TestRegionOpen#testNonExistentRegionReplica fails due to 
NPE
 Key: HBASE-20052
 URL: https://issues.apache.org/jira/browse/HBASE-20052
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu


After HBASE-19391 was integrated, the following test failure can be observed:
{code}
java.lang.NullPointerException
at 
org.apache.hadoop.hbase.regionserver.TestRegionOpen.testNonExistentRegionReplica(TestRegionOpen.java:122)
{code}
This was due null being returned from 
HRegionFileSystem#createRegionOnFileSystem().



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

[jira] [Created] (HBASE-20051) Correct usage statement of endtime for VerifyReplication

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-20051:
---

 Summary: Correct usage statement of endtime for VerifyReplication
 Key: HBASE-20051
 URL: https://issues.apache.org/jira/browse/HBASE-20051
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.3.1, 1.2.2, 1.2.1, 1.3.0, 
1.2.0
Reporter: Sean Busbey
Assignee: Sean Busbey
 Fix For: 1.3.2, 1.2.7


VerifyReplication's usage claims that {{--stoptime}} will give end of time 
range, but then parses {{--endtime}}.

Not an issue on branches that already have HBASE-16772, because it fixed the 
usage as a side effect.



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

Failure: HBase Generate Website

[Apache Jenkins Server]

Build status: Failure

The HBase website has not been updated to incorporate HBase commit 
${CURRENT_HBASE_COMMIT}.

See https://builds.apache.org/job/hbase_generate_website/1262/console

[jira] [Created] (HBASE-20049) Region replicas of SPLIT and MERGED regions are kept in in-memory states until restarting master

[Toshihiro Suzuki (JIRA)]

Toshihiro Suzuki created HBASE-20049:


 Summary: Region replicas of SPLIT and MERGED regions are kept in 
in-memory states until restarting master
 Key: HBASE-20049
 URL: https://issues.apache.org/jira/browse/HBASE-20049
 Project: HBase
  Issue Type: Bug
  Components: read replicas
Reporter: Toshihiro Suzuki
Assignee: Toshihiro Suzuki


Currently, when regions are split or merged, region replicas of the regions 
will become CLOSED state but will not be deleted from in-memory states (e.g. 
AssignmentManager). These region replicas are deleted when restarting master, 
but I think they should be deleted during splitting and merging regions. 
One problem with this is the outdated region replicas can be online. Steps to 
reproduce are as follows:
1. Create a table with enabling region replication.
{code}
create "test", "cf", {REGION_REPLICATION => 2}
{code}

2. Split the table
{code}
split "test"
{code}

3. Disable and enable the table
{code}
disable "test"
enable "test"
{code}

After doing those steps, the outdated region replica will be online.




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