lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Woodward (JIRA)" <>
Subject [jira] [Commented] (SOLR-8323) Add CollectionWatcher API to ZkStateReader
Date Sun, 15 May 2016 17:05:12 GMT


Alan Woodward commented on SOLR-8323:

OK, I think I see what's happening.  

The test waits for a collection to be up, and then registers a watch to check for subsequent
changes.  Once a wait has returned, then the watch is removed, but the collection isn't actually
removed from the 'interesting' list until the next state update.

We have a race between state watchers being cleared after firing and the subsequent removal
of a collection from the 'interesting' list, and the new watcher being added.  On a fast machine,
the new watcher is added before the old one is cleared, and so the state is preserved between
the calls; this means that the new watcher isn't actually fired, because we check if the state
has changed before running notifications.  On a slower machine, the watcher is added afterwards,
so there's no previous state to compare against, so the watcher is fired immediately - resulting
in a test failure, because the test is expecting the state to have changed.

We can fix the test by calling registerCore() first, which puts the collection permanently
on the watched list, but I think there's a bigger question here about how useful statewatchers
are, as opposed to state predicate checks.  All the uses I've come up with so far have just
been waitForState() calls.  [~dragonsinth] what do you think?

> Add CollectionWatcher API to ZkStateReader
> ------------------------------------------
>                 Key: SOLR-8323
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 6.0
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>             Fix For: 6.1
>         Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch,
> An API to watch for changes to collection state would be a generally useful thing, both
internally and for client use.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message