zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2807) Flaky test: org.apache.zookeeper.test.WatchEventWhenAutoResetTest.testNodeDataChanged
Date Fri, 01 Dec 2017 15:46:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16274540#comment-16274540

ASF GitHub Bot commented on ZOOKEEPER-2807:

Github user anmolnar commented on the issue:

    @afine Generally speaking, I like the idea of using LinkedBlockingQueue's intrinsic lock
to wait for becoming empty, but in this particular case I think it's possible that committedRequests
will never be empty if the leader is constantly sending commit requests.
    Correct me if I'm wrong please (there's a very good chance that I completely misunderstand
something), but my feeling is that the following situation is possible:
    1. Learner starts syncing with leader in syncWithLeader() method,
    2. Learner blocks and wait for all commits to be processed before finishing the sync,
    3. FollowerZookeeperServer is already running and keep receiving commits from the Leader
including non-syncing ones,
    4. Learner will never be notified or only at some point in the future much more later
then sync complete or way before that.
    To address this, if we could get the number of commits that we must wait before proceeding,
we would be able to implement a CountDownLatch in CommitProcessor and wait for the number
of commits which are expected in the sync process. However that does not guarantee that we
received all sync-related commits either.
    Otherwise I could also agree with @shralex in the Jira saying: "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.** Even if you
drain the committedRequests, I'm not sure that guarantees that there are no more that will
    That would be the best solution here in my opinion.

> 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

View raw message