[
https://issues.apache.org/jira/browse/BOOKKEEPER-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470220#comment-13470220
]
Rakesh R commented on BOOKKEEPER-420:
-------------------------------------
@Ivan
bq.Has this presented a problem in your testing?
What I have noticed is, bookie which was already acquired lock is again
revisiting one or more times unnecessarily and not giving others a chance. I
have seen after few cycles other guys are able to acquire lock(in tests haven't
seen indefinitely masking other bookies). I just thought of giving fair locking
so all will have equal chance in round robin fashion or could think of some
other fair approach.
@Uma @Ivan
I also agree, not to make code messy to handle this if everyone feels its Ok.
> 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
