Thanks Shawn for your quick answer. When using collection name, Solr will choose the leader, when available in the current server (see getCoreByCollection in SolrDispatchFilter). It is clear that it's useful when indexing. But queries should run on replicas too, don't they? Moreover, the core selection seems to be consistent (that is, it will never get the non-first core in a specific arrangement)...
Under the assumption that a core makes extra work for serving queries (e.g, combining results, processing every non distributed search component (?)), and the assumption that multithreading works well here, Is utilizing all the cores would not be useful? On Sun, Feb 3, 2013 at 11:49 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 2/3/2013 1:18 PM, Isaac Hebsh wrote: > >> Hi. >> >> I have a SolrCloud cluster, which contains some servers. each server runs >> multiple cores. >> >> I want to distribute the requests over the running cores on each server, >> without knowing the cores names in the client. >> >> Question 1: Do I have any reason to do this (when indexing? when >> querying?). >> >> All of these cores are sharing the same system resources, but I guess that >> I still get a better performance if same amount of requests are going to >> each core. Am I right? >> > > If you are using a cloud-aware API (such as CloudSolrServer from SolrJ), > your client knows about your zookeeper setup. Behind the scenes, it > consults zookeeper about how to find the various servers and cores. You > never have to configure any core names on the client. > > If you are not using a cloud-aware API, shouldn't you be talking to the > collection, not the cores? That is, talk to /solr/test, not > /solr/test_shard1_replica1 in your program. That should cause Solr itself > to figure out where the cores are and forward requests as necessary. > Couple that with a load balancer and it approaches what a cloud-aware API > gives you in terms of reliability. > > From my attempts to help people in the IRC channel, I have concluded that > Solr 4.0 may use the name of the collection as the name of the core on each > server. I have not actually used SolrCloud in 4.0, so I cannot say. > > Solr 4.1 does not do this. If you create a collection named test with 2 > shards and 2 replicas with the collections API, you get the following cores > distributed among your servers: > > test_shard1_replica1 > test_shard1_replica2 > test_shard2_replica1 > test_shard2_replica2 > > > Question 2: >> >> I've implemented a nice ServletFilter, which replaces the magic name >> "/randomcore/" with a random core name (retrieved from CoreContainer). I'm >> using RequestDispatcher.forward, on the new URI. It works, very cool :) >> >> But, for making it work, I had to set "<dispatcher>FORWARD</**dispatcher>" >> on >> SolrRequestFilter. this setting is explicitly inadvisable in web.xml. Can >> anyone explain why? >> > > No idea here. > > Thanks, > Shawn > >
