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

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

@Rakesh, even if we have 2 ledgers, shuffling will help as it may try 
alternatively and will get chance for both.

Per your proposal:
I am worrying bit, is that, we may add more lock znodes(number of ledgers to 
replicate* cluster size in worst case) which may be unnecessary when you have 
good cluster. Because they all will participate equally for getting the work 
and at the same time shuffeling will help in randomizing the things. So, same 
Bookies ending up in getting same ledger in a loop will be rare I feel. Window 
will be little high when you have only one ledger to replicate and eligible 
Bookies for replication is very very less.
                
> 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

Reply via email to