Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZOOKEEPER-4655: Communicate the Zxid that triggered a WatchEvent to fire (#1950) #55

Merged
merged 1 commit into from
Aug 31, 2023

Commits on Aug 31, 2023

  1. ZOOKEEPER-4655: Communicate the Zxid that triggered a WatchEvent to f…

    …ire (apache#1950)
    
    * Fix a race condition in WatcherCleanerTest.testDeadWatcherMetrics
    
    Because the metrics were updated _after_ the listener is invoked, the listener does not always see
    the fresh metric value. This fixes it so that the test waits for the value to become what we expect.
    
    * Leverage an existing method and refactor the rest of the code to match
    
    Since there was an existing waitFor method in ZKTestCase, along with an existing implementation of a
    waitForMetric LearnerMetricsTest, this commit moves waitForMetric to ZKTestCase and refactors the
    metric-related usages of waitFor.
    
    * Communicate the Zxid that triggered a WatchEvent to fire
    
    With the recent addition of persistent watches, many doors have opened up to significantly more
    performant and intuitive local caches of remote state, but the actual implementation can be
    difficult because to cache data locally, one needs to execute the following steps:
    
    1. Set the watch
    2. Bootstrap the watched subtree
    3. Catch up on the events that fired during the bootstrap
    
    The issue is it's now very difficult to deduplicate and sanely resolve the remote state during step
    3 because it's unknown whether an event arrived during the bootstrap or after. For example,
    imagine that between steps 1 and 2, a node /a was deleted then re-created. By the time step 3 is
    executed, there will be a NodeDeleted event queued up followed by a NodeCreated, causing at best a
    double read (one from the bootstrap, one from the NodeCreated) or at worst some data inconsistencies
    in the local cache.
    
    This change sets the Zxid in the response header whenever the watch event type is NodeCreated,
    NodeDeleted, NodeDataChanged or NodeChildrenChanged.
    PapaCharlie authored and anurag-harness committed Aug 31, 2023
    Configuration menu
    Copy the full SHA
    9ca1d33 View commit details
    Browse the repository at this point in the history