I think you meant to say that the shard has MORE than 1 replica. If a shard has only 1 replica, then a query to that shard can only go to that one node.
Also, the leader is by definition a replica as well. So, where you say "the leader or replica", that should be "a replica which may happen to be the leader for the shard". For SolrCloud, you should be using CloudSolrServer, not LBHTTPSolrServer. Currently, Solr has no concept of sessions. The caches serve all clients, not some specific client or "session". The idea is that a lot of queries are common across users, so a given query is likely to have been queried recently by another user. -- Jack Krupansky On Sat, Feb 14, 2015 at 3:39 PM, jaime spicciati <jaime.spicci...@gmail.com> wrote: > All, > This is my current understanding of how SolrCloud load balancing works... > > Within SolrCloud, for a cluster with more than 1 shard and at least 1 > replica, the Zookeeper aware SolrJ client uses LBHTTPSolrServer which is > round robin across the replicas and leaders in the cluster. In turn the > shard (which can be a leader or replica) that performs the distributed > query may then go to the leader or replica for each shard based on round > robin via LBHTTPSolrServer. > > If this is correct then in a SolrCloud instance that has let's say 1 > replica, the initial query from the user may go to the leader for shard 1, > then when the user paginates to the second page the subsequent query may go > to the replica of shard 1. This seems inefficient from a caching > perspective where the queryResultCache and possibly the filterCache would > need to be reloaded. > > From what I can find there does not appear to be any option of session > affinity within the SolrCloud query execution? > > > Thanks! >
