You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Alan Woodward (JIRA)" <ji...@apache.org> on 2015/11/16 11:30:10 UTC

[jira] [Commented] (SOLR-8280) TestCloudSchemaless + ChangedSchemaMergeTest fail weirdly if you try to use SolrCoreAware sim factory: SchemaSimilarityFactory

    [ https://issues.apache.org/jira/browse/SOLR-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006470#comment-15006470 ] 

Alan Woodward commented on SOLR-8280:
-------------------------------------

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, a) during core initialization when we need to call init() immediately, but wait to call inform() until after the loading latch has been released, and then b) to create new objects once the core is up and serving queries.  I tried to split this out into two separate SRL implementations, one of which is private to SolrCore and used only in the constructor, and does the call-init-and-then-delay-inform dance, and the other of which is returned by SolrCore.getResourceLoader() and inits() and informs() before it returns.  To be honest though, I get so confused by the code paths here that I'm not sure whether or not that would help in this case...

> 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__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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org