8.7.0 SchemaManager not respecting UPDATE_TIMEOUT_SECS

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

8.7.0 SchemaManager not respecting UPDATE_TIMEOUT_SECS

Tiziano Degaetano

I’m running some test on solr 8.7.0 with embedded zookeeper.

I have an issues that sometimes after changing the schema the very next call is still running against the old schema returning wrong results.
A retry or a small wait will fix the issue, but this makes it hard to test as UPDATE_TIMEOUT_SECS would suggest the call is only returned after the schema is updated and cores are reloaded.
This issue is new in 8.7 I can not be reproduce it in 8.6.

Debugging the code I realized that SolrCore.getConfListener is reloading the core simultaneously to the schema change in  https://github.com/apache/lucene-solr/blob/b78be96da564ef44543c64b5c9dbcd786c4b605d/solr/core/src/java/org/apache/solr/core/SolrCore.java#L3134

This makes the SchemaManager return in CoreContainer.reload immediately as the id of the core has been (is being) reloaded already  https://github.com/apache/lucene-solr/blob/b78be96da564ef44543c64b5c9dbcd786c4b605d/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L1710
Basically this change in 8.7 causes the issue, I guess in 8.6 we have multiple reloads.

From my Point of view either the SchemaManager should acquire a readerLock to disable SolrCore.getConfListener reloads while updating the schema or CoreContainer.reload should await somehow that the reloaded core is available before returning in line 1710.

I could not find any open issues in jira related to 8.7 and CoreContainer reload. Not sure if this is related to https://issues.apache.org/jira/browse/SOLR-13709 as the bug is from last year.

Kind regards,