Yeah, shards.qt is the way to go. I think this basically done because of a limitation around early distrib search.
If you want to do a distrib search against a bunch of shards and you put the shards to search into the request handler, you then don't want to hit that same request handler on the subsearches or it will just keep sub searching those nodes over and over. So usually it was recommended you create a second search handler with the shards param. Distrib search is then setup so that sub searches call the /select handler using the params from the custom handler you added. "shards" gets removed though, and since it's not set in the /select handler you don't infinitely loop. I think with something like SolrCloud this is not a problem - you don't hardcode shards in the request handler. It's also not a problem if you specify shards on your query instead. It does make using some components awkard - it's not usually immediately clear how to add a distrib component - but you usually end up setting shards.qt so that you don't jump to the select handler. If you must hard code shards in the config, you can try other things like also adding the component to the /select handler. I think it would be nice to clean this up a bit somehow. Or document it better. - Mark On Jan 18, 2013, at 3:39 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 1/18/2013 1:20 PM, Mike Schultz wrote: >> Can someone explain the logic of not sending the qt parameter down to the >> shards? >> >> I see from here that qt is handled as a special case for ResultGrouping: >> http://lucidworks.lucidimagination.com/display/solr/Result+Grouping >> where there is a special shard.qt parameter. >> >> in 3.x solrconfig.xml supports defining a list of SearchComponents on >> handler by handler basis. This flexibility goes away if qt isn't passed >> down or am I missing something? >> >> I'm using: >> <requestDispatcher handleSelect="true> for the legacy behavior. We want to >> be able to have a single endpoint (e.g. http://localhost:8983/solr/select) >> and modify query processing by varying only the query parameters. > > Just add shards.qt with the appropriate value in each solrconfig.xml handler > definition that needs it. That should work for most use cases. > > Thanks, > Shawn >
