Hey Solr community, I found myself doing some maintenance inside QueryElevationComponent related to some much larger refactoring. I'm seeing a fair amount of complexity around it's support of "elevate.xml" in a Solr *data* directory (where the index is). I don't know of any other Solr component that does anything like this. This feature of QEC existed from the start in Jan 2008. In October of that same year, Solr's replication handler gained the ability to replicate config files (see "confFiles" option) between cores. I think this aspect of QEC would not have existed if it came later. In SolrCloud, you're expected to use ZooKeeper of course.
I plan to remove this mechanism in 9.0 on the grounds that it is obsolete. To account for the ability to automatically detect elevate.xml changes in a data dir and reload on a commit, I'm adding this mechanism to the configSet/conf. I'm not doing so for SolrCloud at this time because of overhead concerns but it could be added later with some work. I also plan to remove QEC's support of the elevate.xml file to be "versioned" -- e.g. elevate.xml.001, elevate.xml.002. The underlying mechanism was added in https://issues.apache.org/jira/browse/SOLR-351 where it was argued to be useful for Windows OS which cannot replace an already open file. Obviously this is a non-issue in SolrCloud, and perhaps not an issue if you use the confFiles replication feature to edit it either. Regardless, I'm highly suspicious it's an issue whatsoever since this file shouldn't be held open on a sustained basis; it's only loaded on core load / replication and with my changes above, on a commit if the modification time changes. If you have concerns, let me know. SOLR-15274 - QueryElevationComponent: auto-load file changes; remove data dir support <https://issues.apache.org/jira/browse/SOLR-15274> ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
