David Smiley created SOLR-14652:
-----------------------------------
Summary: SolrCore should hold its own CoreDescriptor
Key: SOLR-14652
URL: https://issues.apache.org/jira/browse/SOLR-14652
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
Assignee: David Smiley
SolrCore.getCoreDescriptor() surprisingly must do
{{coreContainer.getCoreDescriptor(name)}} instead of simply return a field on
itself. I think it's more sane that a SolrCore hold onto its own descriptor
making it unequivocally clear it will get it. I've seen a transient-core edge
case where it didn't, though I don't want to classify this issue as a bug fix
over that.
Also:
* SolrCore's constructors don't need a "name" since it's guaranteed to always
be the name in the coreDescriptor. I checked.
* SolrCore's constructor shouldn't call
{{coreContainer.solrCores.addCoreDescriptor(cd);}} because it's the container's
responsibility to manage such things. I made SolrCores.putCore ensure the
descriptor is added, and this is called by CoreContainer.registerCore which is
called after new SolrCore instances are created.
* solrCore.setName should only be called when we expect the name to change.
Furthermore that shouldn't ever happen in SolrCloud so I added checks.
* solrCore.setName calls {{coreMetricManager.afterCoreSetName()}} which is
something that is really only related to a _rename_, not name initialization
(from the constructor). I renamed that method and further only call it if the
name did change from non-null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
