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:06: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:05 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". 

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.

> 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