lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-5028) Incorrect ShardHandlerFactory creation
Date Thu, 11 Jul 2013 11:39:49 GMT

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

Tomás Fernández Löbbe commented on SOLR-5028:
---------------------------------------------

bq. Tomás: Don't quite get this. Those enums are just for use as key values in the map, not
for the paths so I think they should stay.
Yes, I know, but what I'm saying is that as the SHF receives an unknown set of parameters
(because it's a plugin) you can't generate enum keys for everything. Instead of that, when
someone needs to get information about the SHF configuration it'll need to get the Node (or
the PluginInfo with Alan's patch). "connTimeout" and "socketTimeout" are arguments specific
to the HttpShardHandlerFactory that other SHF implementations may or may not use. Also, HttpShardHandlerFactory
accepts lots of other arguments and we are not providing keys for all of them. So it gets
confusing, some arbitrary init params can be get using cfg.get(...) and some can't. 

bq. Ryan, Tomás, could you try this out? Will work on a persistence patch next.
I haven't tested it yet, but +1 on the changes you did. ConfigSolrXmlOld still populates the
map with the wrong paths though. 
                
> Incorrect ShardHandlerFactory creation
> --------------------------------------
>
>                 Key: SOLR-5028
>                 URL: https://issues.apache.org/jira/browse/SOLR-5028
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 5.0, 4.4
>            Reporter: Tomás Fernández Löbbe
>         Attachments: SOLR-5028.patch, SOLR-5028.patch, SOLR-5082.patch
>
>
> It seems to me that there are two bugs in the ShardHandlerFactoryCreation that cancel
each other and it seems to be working with the old style solr.xml, but not with the "new style".
ConfigSolrOldXml seems to be expecting the shardHandlerFactory with the xpath:
> solr/shardHandlerFactory/@class
> Instead of solr/*cores*/shardHandlerFactory/@class as it used to be. This is never caught
because in the CoreContainer the ShardHandlerFactory is initialized using "configSolr.getConfig().getNode("solr/cores/shardHandlerFactory",
false);" instead of "configSolr.get(CfgProp.SOLR_SHARDHANDLERFACTORY_CLASS, null);" or something
like that. However, if you use the "new style" xml, the CoreContainer will still try to initialize
the factory like that, and won't find the  SHF. 

--
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


Mime
View raw message