You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2020/03/27 03:51:00 UTC
[jira] [Resolved] (SOLR-14342) CoreSorter is partially broken, thus
core loading order is sub-optimal
[ https://issues.apache.org/jira/browse/SOLR-14342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley resolved SOLR-14342.
---------------------------------
Fix Version/s: 8.6
Resolution: Fixed
> CoreSorter is partially broken, thus core loading order is sub-optimal
> ----------------------------------------------------------------------
>
> Key: SOLR-14342
> URL: https://issues.apache.org/jira/browse/SOLR-14342
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: scaling
> Fix For: 8.6
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In SOLR-7280, it Solr was supposedly improved to load cores in a more optimal order in SolrCloud, considering the state of collections across the cluster. The CoreContainer uses CoreSorter for this. Unfortunately, CoreSorter's attempts to gather statistics early on in CoreSorter.init() operate on an empty list and do nothing (i.e. dead code). The root cause is that getCloudDescriptors() works by looking at cc.getCores however at this stage _there are no cores_ ! (We haven't sorted them so they certainly haven't been loaded yet. I have a fix.
> This might be classified as a bug fix but the core load order is more about optimization, so a fix to a wrong/incomplete optimization isn't really a bug from a user's point of view.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org