[
https://issues.apache.org/jira/browse/SOLR-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17306513#comment-17306513
]
Chris M. Hostetter commented on SOLR-15274:
-------------------------------------------
{quote}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.
{quote}
The key distinction was that when loaded as a config file, it was read "once"
on SolrCore init. If instead you hosted in the dataDir, then it would be
checked & reloaded on every new SolrIndexSearcher.
ie: it was specifically designed for people who wish to modify elevate.xml
frequently w/o needing a full core reload, while trying to implement it in a
way that wouldn't cause a lot of per-request overhead for people who were happy
with a "static" list of elevations.
{quote}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.
{quote}
Can you elaborate on how you intend for this to work (I skimmed your patch but
got a little lost in terms of where/how QEC is going to decide if the "conf"
file has changed?)
it seems like making QEC (or a subclass of it) aware of ZK and "watching" the
elevate.xml would be the ideal way to deal with this, but your comment about
*NOT* doing it for SolrCloud confuses me.
----
Final note: given that QEC has never required any special configuration in
order to try looking for elevate.xml in the data dir, I would suggest that
after this change QEC should log an ERROR if it sees an elevate.xml in the data
dir (whether it should fail to init at all if it sees this file i'm less
opinionated about)
> QueryElevationComponent: auto-load file changes; remove data dir support
> ------------------------------------------------------------------------
>
> Key: SOLR-15274
> URL: https://issues.apache.org/jira/browse/SOLR-15274
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> QueryElevationComponent can detect changes to its elevate.xml file and load
> it following a commit (new searcher). But this only works when the file is
> in the "data" dir, which is weird. I wish to +remove+ support for the data
> dir and add this auto-loading mechanism to standard conf/configSet location.
> Additionally, I wish to +remove+ QEC's support of the elevate.xml file to be
> "versioned" -- e.g. elevate.xml.001, elevate.xml.002.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
