[
https://issues.apache.org/jira/browse/SOLR-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132155#comment-18132155
]
Nick Shanin commented on SOLR-4669:
-----------------------------------
>From code reading against apache/main b73f03976fa, IndexFetcher copies the
>configuration files before installing the new index
>(solr/core/src/java/org/apache/solr/handler/IndexFetcher.java:745, 747-773)
>and reloads the core after
>(solr/core/src/java/org/apache/solr/handler/IndexFetcher.java:790). The order
>in the ticket, new index with old config, does not occur. Is closure OK, or is
>there still a failing order?
🤖 AI-generated 🤖
> conf file replication can cause new index to be loaded before new core (with
> new configs) is loaded.
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-4669
> URL: https://issues.apache.org/jira/browse/SOLR-4669
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Reporter: Chris M. Hostetter
> Priority: Major
>
> Unless i'm smoking crack, some behavior i noticed working on SOLR-4629
> indicates that when solr replication detects both a changed index, and
> changed config files, the index is copied over and put into use by the
> current solr core, then the conig files are copied over, and then the solr
> core is reloaded with the modified configs.
> which means there is a window of time in which the "new" index is being
> searched using the old configs -- which could have bizare consequences.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
