bszabo97 opened a new pull request #462:
URL: https://github.com/apache/solr/pull/462


   https://issues.apache.org/jira/browse/SOLR-15830
   
   <!--
   _(If you are a project committer then you may remove some/all of the 
following template.)_
   
   Before creating a pull request, please file an issue in the ASF Jira system 
for Solr:
   
   * https://issues.apache.org/jira/projects/SOLR
   
   You will need to create an account in Jira in order to create an issue.
   
   The title of the PR should reference the Jira issue number in the form:
   
   * SOLR-####: <short description of problem or changes>
   
   SOLR must be fully capitalized. A short description helps people scanning 
pull requests for items they can work on.
   
   Properly referencing the issue in the title ensures that Jira is correctly 
updated with code review comments and commits. -->
   
   
   # Description
   
   When using Schema API SchemaManager class triggers a core reload here: 
https://github.com/apache/solr/blob/cfc953b6b906ef742bba57024d327fbde5d564c2/solr/core/src/java/org/apache/solr/schema/SchemaManager.java#L132
   
   As I understand this was introduced in SOLR-9832 and is useful to avoid 
accidentally reloading to an older version of the config. The problem is that 
in the solr core a listener is implemented to initiate a reload whenever a 
config change happens in ZK, this can be found here: 
https://github.com/apache/solr/blob/cfc953b6b906ef742bba57024d327fbde5d564c2/solr/core/src/java/org/apache/solr/core/SolrCore.java#L3140
   
   When updating the schema using the Schema API both of these reloads get 
triggered and this can result in a strange bug, where not all the indexed 
documents are visible if the indexing is started just after the schema API 
returned.
   
   # Solution
   
   I added a check and lock which is the same as in SolrCore to check if there 
is another reload in progress and makes sure no other reload can be started.
   
   # Tests
   
   I added a test which points out this bug: when the test is run without the 
lock in SchemaManager the test fails because the query returns less documents 
than the expected but more than 0. If the lock is in place the test succeeds.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [x] I have developed this patch against the `main` branch.
   - [x] I have run `./gradlew check`.
   - [x] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to