On 6/21/10 4:58 PM, Chris Hostetter wrote:
: I registered a request handler named after my application. Aside from : various defaults that I configured, I also registered some components : I've written. When I tried to do a distributed search, I noticed that : the secondary Solr requests internal to the workings of the distributed : search were going to the standard request handler, not the one fielding : the distributed search. As such, I found it necessary to duplicate my can you elaborate on what you mean by "standard request handler" ? ... what is hte actual URL that shows up in your access log on each of hte shards? I believe what may be happening is that when you execute a query like... http://coordinator/solr/foobar?shard=shardA/solr/1,shardB/solr/2&;... ...the resulting distributed queries look like... http://shardA/solr/1/select?qt=/foobar&;... http://shardB/solr/2/select?qt=/foobar&;... ...which should work, assuming you have the 'handleSelect="true"' option in your solrconfig.xml (the only reason not to have it is if you need to support really ugly legacy formating behavior from the /select URL, and if you are using distributed searching then presumably you aren't stuck in hte dark ages) NOTE: this is largely speculation on my part ... i haven't tested to verify that's actually what it's doing. (I also have a vague recollection that this may have changed in Solr 1.4 to be less confusing) -Hoss
I think - and this doesn't appeared to be doc'd anywhere so I don't know for sure - but if I remember right, there is a shards.qt param - if that is set, that's the handler used for sub shards - otherwise select is used.
The distrib wiki is pretty light in general though - doesn't even mention the infinite loop problem that's easy to stumble upon.
-- - Mark http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
