[
https://issues.apache.org/jira/browse/BOOKKEEPER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470054#comment-13470054
]
Rakesh R commented on BOOKKEEPER-420:
-------------------------------------
Hi,
Just few thoughts to begin discussion:-
I'm thinking to queue-up the locks using ephemeral sequence znode to give fair
chance to all the RWs like below. Here each guy will add watcher to his
predecessor znode instead of 'urL0000000004' and act on znode deletion.
/ledgers/underreplication/locks/urL0000000004/L_0001, L_0002, L_0003, L0004,
L0005. Always the lowest entity will get the lock and continue to rereplicate.
> 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
