Intuitively this may not be the right place for such a fix - this probably should be higher level - making sure that follower does not even accept local ops before properly completing the sync. On Thu, Jul 6, 2017 at 4:11 PM Abraham Fine (JIRA) <[email protected]> wrote:
> > [ > 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) >
