[jira] [Commented] (BOOKKEEPER-420) Lock does not guarantee any access order and not giving chance to longest-waiting RW

["Uma Maheswara Rao G (JIRA)" <ji...@apache.org>]

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

Uma Maheswara Rao G commented on BOOKKEEPER-420:
------------------------------------------------

As we are shuffeling once we get the childrens, this problem may not come when you have more than one ledger to replicate. There is a chance of this problem rarely when you have only one ledger to replicate and also that eligible target Bookie is slow when compared to others and all other Bookies are not eligible to replicate. 
                
> Lock does not guarantee any access order and not giving chance to longest-waiting RW
> ------------------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-420
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-420
>             Project: Bookkeeper
>          Issue Type: Sub-task
>          Components: bookkeeper-auto-recovery
>            Reporter: Rakesh R
>            Assignee: Rakesh R
>             Fix For: 4.2.0
>
>
> Improve the distributed lock by giving fair chance to all the RW. Presently few RW can again and again acquire lock and pushing other RW away from rereplication.
> +Example:+
> Have five RWs...RW1, RW2, RW3, RW4, RW5. 
> Say L0000000004 is underreplicated and RW1 acquired lock. Meantime all others will add watcher to this lock. After replication assume RW2 acquired lock and all others(including RW1) will be adding watcher. Here after RW2 releases, again RW1 can be more aggressive and acquire the lock. This will push others to starvation.

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