[
https://issues.apache.org/jira/browse/SOLR-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8280:
---------------------------
Attachment: SOLR-8280.patch
bq. I have a half-implemented patch hanging around somewhere that tried to
clean this up a bit. I think the root problem is that there are two
circumstances in which we're using SolrResourceLoader, ...
Agreed. It's a mess, and it would be nice to clean up -- but that's a huge
pile of work, so i'd prefer to punt it to another issue. (which i will file
soon)
----
After digging into things a bit more, here are a few things i
learned/realized/uncovered in no particular order...
* in most cases, the schemaless/managed-schema code paths don't actaully
replace the entire IndexSchema used by a SolrCore...
** REST APIs use things like {{ManagedIndexSchema.addFieldTypes(...)}} which do
shallow copies
*** these ManagedIndexSchema methods for mutating things and doing shallow
copies already have smarts to ensure that any new {{ResourceAware}} objects get
properly informed.
*** since there is no way to dynamically change the SimFactory at run time, the
existing instance is re-used in all of these shallow copies and no new
SimFactory instances ever need informed of the core
** some (cloud specific) code paths use things like
{{ZkIndexSchemaReader.updateSchema}} to notice if/when the schema file changes
in ZK and act on that locally
*** this does (evidently) construct an entirely new ManagedIndexSchema instance
*** this is the code path that was execing after {{TestCloudSchemaless}} was
finished -- but I still understand when/why this was happening.
** ChangedSchemaMergeTest is kind of a special case, because it goes out of
it's way to construct a new IndexSchema and set it on an existing SolrCore even
though it isn't using MangedIndexSchema
* There was already a special kludge for SolrCoreAware SimFactories in
{{SolrCore.initSchema}}
** looks like this was originally for ensuring that the SimFactories was usable
when other SolrCoreAware things (like listeners) got informed of the SolrCore
and tried to use the SolrIndexSearcher (which depended on the sim)
So i think the most straight forward solution to the problem
(SimilarityFactory-ies that implement SolrCoreAware playing nice with managed
schema) is to refactor that existing kludge from {{SolrCore.initSchema}} to
{{SolrCore.setLatestSchema}}
----
Current Patch...
* schema-add-schema-fields-update-processor.xml - explicitly use
SchemaSimilarityFactory here to help stress TestCloudSchemaless
* ChangedSchemaMergeTest - explicitly use SchemaSimilarityFactory here to test
that scenerio
* SolrCore - refactored existing SolrCoreAware simfactory hack so that it
applies anytime setLatestSchema is called
* SchemaSimilarityFactory - switched from assertions to IllegalStateException
so it's more obvious there's a problem even if assertions are disabled (no NPE)
* SolrResourceLoader - has some nocommits i want to update with strong warnings
and a link to a new jira where my & alan's comments about the lifecycle
problems of objects inited _after_ the SolrCore is loaded are tracked
----
TODO:
* cleanup & beef up nocommit comments
* beef up ChangedSchemaMergeTest to actually change the sim used in each schema
& verify it's updated (and fully functional)
* add/update a managed schema test that does an add-field type w/ a
per-fieldtype sim and sanity check that code path + input works properly and
plays nicely with SchemaSimilarityFactory
> TestCloudSchemaless + ChangedSchemaMergeTest fail weirdly if you try to use
> SolrCoreAware sim factory: SchemaSimilarityFactory
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8280
> URL: https://issues.apache.org/jira/browse/SOLR-8280
> Project: Solr
> Issue Type: Bug
> Affects Versions: Trunk
> Reporter: Hoss Man
> Attachments: SOLR-8280.patch, SOLR-8280.patch, SOLR-8280.patch,
> SOLR-8280__broken__resource_loader_experiment.patch
>
>
> Something about the code path(s) involved in TestCloudSchemaless &
> ChangedSchemaMergeTest don't play nicely with a SimilarityFactory that is
> SolrCoreAware -- notably: SchemaSimilarityFactory.
> I discovered this while trying to implement SOLR-8271, but it can be
> reproduced trivially by modifying the
> schema-add-schema-fields-update-processor.xml file used by
> TestCloudSchemaless (and hardcoded in java schema used by
> ChangedSchemaMergeTest) to refer to SchemaSimilarityFactory explicitly.
> Other cloud tests (such as CollectionReloadTest) or cloud+schemaless (ex:
> TestCloudManagedSchema) tests don't seem to demonstrate the same problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
