zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abraham Fine (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ZOOKEEPER-2807) Flaky test: org.apache.zookeeper.test.WatchEventWhenAutoResetTest.testNodeDataChanged
Date Thu, 06 Jul 2017 23:11:00 GMT

    [ 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)

Mime
View raw message