You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Phil Yang (JIRA)" <ji...@apache.org> on 2016/07/01 03:53:11 UTC

[jira] [Commented] (HBASE-16144) Replication queue's lock will live forever if RS acquiring the lock has died prematurely

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

Phil Yang commented on HBASE-16144:
-----------------------------------

Here array.length will always positive, so i think it is OK

The timestamp of mtime is set by zk, which is always System.currentTimeMillis(), if we use EnvironmentEdge, it may be wrong when it is not System.currentTimeMillis()?

Will fix other issues soon

> Replication queue's lock will live forever if RS acquiring the lock has died prematurely
> ----------------------------------------------------------------------------------------
>
>                 Key: HBASE-16144
>                 URL: https://issues.apache.org/jira/browse/HBASE-16144
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.2.1, 1.1.5, 0.98.20
>            Reporter: Phil Yang
>            Assignee: Phil Yang
>         Attachments: HBASE-16144-v1.patch
>
>
> In default, we will use multi operation when we claimQueues from ZK. But if we set hbase.zookeeper.useMulti=false, we will add a lock first, then copy nodes, finally clean old queue and the lock. 
> However, if the RS acquiring the lock crash before claimQueues done, the lock will always be there and other RS can never claim the queue.



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