[
https://issues.apache.org/jira/browse/ZOOKEEPER-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16077315#comment-16077315
]
Abraham Fine edited comment on ZOOKEEPER-2807 at 7/6/17 11:10 PM:
------------------------------------------------------------------
[~shralex] So my understanding is that one of the major changes to the commit
processor introduced in ZOOKEEPER-2024 is to change the main "run loop" of the
CommitProcessor from processing all of the `committedRequests` queue on each
iteration to processing only "a single committed request" (in order to prevent
starvation I imagine).
So I believe this change substantially increases the probability that there
will be new incoming requests in `queuedRequests` processed before older
requests in`committedRequests`. This is generally fine, except when catching up
to a leader. This patch adds a mechanism to make wait until `committedRequests`
has been "drained" before we start "following". This way we know that all
commits from the leader are applied to the DB before we begin handling incoming
requests.
I'm pretty confident that my patch will not have a real performance impact
since the code path is unchanged unless there is 1 entry in committedRequests.
I need some time to take a look at ZOOKEEPER-2684, grok whats going on, and see
if it has anything to do with the fix here.
was (Author: abrahamfine):
[~shralex] So my understanding is that one of the major changes to the commit
processor introduced in ZOOKEEPER-2024 is to change the main "run loop" of the
CommitProcessor from processing all of the `committedRequests` queue on each
iteration to processing only "a single committed request" (in order to prevent
starvation I imagine).
So I believe this change substantially increases the probability that there
will be new incoming requests in `queuedRequests` processed before older
requests in`committedRequests`. This is generally fine, except when catching up
to a leader. This patch adds a mechanism to make wait until `committedRequests`
has been "drained" before we start "following".
I'm pretty confident that my patch will not have a real performance impact
since the code path is unchanged unless there is 1 entry in committedRequests.
I need some time to take a look at ZOOKEEPER-2684, grok whats going on, and see
if it has anything to do with the fix here.
> Flaky test:
> org.apache.zookeeper.test.WatchEventWhenAutoResetTest.testNodeDataChanged
> -------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2807
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2807
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Abraham Fine
> Assignee: Abraham Fine
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
