[ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649405#comment-13649405 ]
Erick Erickson edited comment on SOLR-4478 at 5/5/13 7:58 PM:
--------------------------------------------------------------
Updated patch with a problem. First I had the bright idea to interleave the configset-style and new-style core.properties files so we'd get some added testing done in OpenCloseCoreStressTest. Tests passed first time! Except for the stack traces, turns out I was eating an exception in the test that I shouldn't have been. Fortunately it seems to be a stack trace only thrown by the new code. NOTE: There's a nocommit in OpenCloseCoreStressTest that forces all cores to be configset only for easier debugging on this issue.
But looking at the stack trace, there's an NPE at SearchHandler.180 or so, this line:
ShardHandler shardHandler1 = shardHandlerFactory.getShardHandler();
Of course the shardHandlerFactory is null here.
So two things:
1> Does it even make sense to share the SolrConfig object? I can imagine all sorts of threading issues here, but don't know the underlying code well enough to know whether to be terrified or not.
2> Any clue why the shardHandlerFactory would be null? Near as I can tell, the SolrResourceLoader.inform method is where the problem starts, it sets the "live" member variable and later the NPE happens since the "live" member var aborts processing in the newInstance method.
And if it's as simple as giving each core a new ResourceLoader, is there any point or is the work required at that point enough that sharing the solrconfig isn't worth the effort.
Of course it may just be a sequencing issue, but I'm a little lost today, any wisdom gratefully received.
was (Author: erickerickson):
Updated patch with a problem. First I had the bright idea to interleave the configset-style and new-style core.properties files so we'd get some added testing done. Tests passed first time! Except for the stack traces, turns out I was eating an exception in the test that I shouldn't have been. Fortunately it seems to be a stack trace only thrown by the new code.
But looking at the stack trace, there's an NPE at SearchHandler.180 or so, this line:
ShardHandler shardHandler1 = shardHandlerFactory.getShardHandler();
Of course the shardHandlerFactory is null here.
So two things:
1> Does it even make sense to share the SolrConfig object? I can imagine all sorts of threading issues here, but don't know the underlying code well enough to know whether to be terrified or not.
2> Any clue why the shardHandlerFactory would be null? Near as I can tell, the SolrResourceLoader.inform method is where the problem starts, it sets the "live" member variable and later the NPE happens since the "live" member var aborts processing in the newInstance method.
And if it's as simple as giving each core a new ResourceLoader, is there any point or is the work required at that point enough that sharing the solrconfig isn't worth the effort.
Of course it may just be a sequencing issue, but I'm a little lost today, any wisdom gratefully received.
> Allow cores to specify a named config set
> -----------------------------------------
>
> Key: SOLR-4478
> URL: https://issues.apache.org/jira/browse/SOLR-4478
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.2, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-4478.patch, SOLR-4478.patch
>
>
> Part of moving forward to "the new way", after SOLR-4196 etc... I propose an additional parameter specified on the <core> node in solr.xml or as a parameter in the "discovery" mode core.properties file, call it configSet, where the value provided is a path to a directory, either absolute or relative. Really, this is as though you copied the conf directory somewhere to be used by more than one core.
> Straw-man: There will be a directory <solr_home>/configsets which will be the default. If the configSet parameter is, say, "myconf", then I'd expect a directory named "myconf" to exist in <solr_home>/configsets, which would look something like
> <solr_home>/configsets/myconf/schema.xml
> solrconfig.xml
> stopwords.txt
> velocity
> velocity/query.vm
> etc.
> If multiple cores used the same configSet, schema, solrconfig etc. would all be shared (i.e. shareSchema="true" would be assumed). I don't see a good use-case for _not_ sharing schemas, so I don't propose to allow this to be turned off. Hmmm, what if shareSchema is explicitly set to false in the solr.xml or properties file? I'd guess it should be honored but maybe log a warning?
> Mostly I'm putting this up for comments. I know that there are already thoughts about how this all should work floating around, so before I start any work on this I thought I'd at least get an idea of whether this is the way people are thinking about going.
> Configset can be either a relative or absolute path, if relative it's assumed to be relative to <solr_home>.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org