zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: [jira] [Comment Edited] (ZOOKEEPER-2807) Flaky test: org.apache.zookeeper.test.WatchEventWhenAutoResetTest.testNodeDataChanged
Date Thu, 06 Jul 2017 23:15:22 GMT
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) <jira@apache.org> 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)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message