You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2021/05/14 20:17:00 UTC

[jira] [Updated] (HBASE-25613) [Branch-2 and Master]Handle the NoNode exception in remove log replication in a better way then just log WARN

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

Andrew Kyle Purtell updated HBASE-25613:
----------------------------------------
    Fix Version/s:     (was: 2.4.3)
                   2.4.4

> [Branch-2 and Master]Handle the NoNode exception in remove log replication in a better way then just log WARN
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-25613
>                 URL: https://issues.apache.org/jira/browse/HBASE-25613
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Sandeep Pal
>            Assignee: Sandeep Pal
>            Priority: Major
>             Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.4
>
>
> Currently, when we see the NoNodeException in the replication source while removing a log from ZK, we swallow that exception and log WARN. 
>  
> In certain cases, we might have the peer removed and corresponding logs removing as well but the replication source continuous to run because of an RPC failure or anything. 
> In stead of just log WARN we should check if the peer is removed, if it is the case, we should terminate the source or try to execute the removePeer workflow again.
>  
> This would prevent the orphaned source execution infinitely. 



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