[ 
https://issues.apache.org/jira/browse/SOLR-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283882#comment-15283882
 ] 

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: https://issues.apache.org/jira/browse/SOLR-8323
>             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, 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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to