[jira] [Commented] (SOLR-11535) Weird behavior of CollectionStateWatcher

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] [Commented] (SOLR-11535) Weird behavior of CollectionStateWatcher

JIRA jira@apache.org

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

Tomás Fernández Löbbe commented on SOLR-11535:

This may be related to the fact that we execute ZooKeeper watches in a multi-thread executor, so if multiple threads in parallel could call the {{StateWatcher.refreshAndWatch}} method concurrently (coming from two watches fired on the same znode). Note that we re-set the watch when we call {{fetchCollectionState}}. This is similar to what I saw while working on SOLR-12172.
 Maybe the solution is to not call {{constructState}} when {{updateWatchedCollection}} returns {{false}}. Other option I think could be to put
DocCollection newState = fetchCollectionState(coll, this);
updateWatchedCollection(coll, newState);
inside the synchronize. Other option is to document that the watchers could be called more than once for the same data and make the watcher call handle it. Maybe [~shalinmangar] also has some thoughts.

> Weird behavior of CollectionStateWatcher
> ----------------------------------------
>                 Key: SOLR-11535
>                 URL: https://issues.apache.org/jira/browse/SOLR-11535
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public)
>    Affects Versions: 7.2, master (8.0)
>            Reporter: Andrzej Bialecki
>            Priority: Major
>         Attachments: test.log
> While working on SOLR-11320 I noticed a strange behavior in {{ActiveReplicaWatcher}}, which is a subclass of {{CollectionStateWatcher}} - it appears that its {{onStateChanged}} method can be called from multiple threads with exactly the same {{DocCollection}} state, ie. unchanged between the calls.
> This seems to run contrary to the javadoc, which implies that this method is called only when the state actually changes, and it also doesn't mention anything about the need for thread-safety in the method implementation.
> I attached the log, which has a lot of additional debugging - but the most pertinent part being where a Watcher-s hashCode is printed together with the {{DocCollection}} - notice that these overlapping calls both submit an instance of {{DocCollection}} with the same zkVersion.
> [~dragonsinth], [~romseygeek] - could you please take a look at this? If this behavior is expected then the javadoc should be updated to state clearly that multiple calls can be made concurrently, with exactly the same state (which is kind of a weak guarantee for a method called {{onStateChanged}} ;) ).

This message was sent by Atlassian JIRA

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