Thanks for the correction Shawn. Yes its only the heap allocation settings are per host/JVM.
On Fri, Jun 2, 2017 at 9:23 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 6/1/2017 11:40 PM, Daniel Angelov wrote: > > Is the filter cache separate for each host and then for each > > collection and then for each shard and then for each replica in > > SolrCloud? For example, on host1 we have, coll1 shard1 replica1 and > > coll2 shard1 replica1, on host2 we have, coll1 shard2 replica2 and > > coll2 shard2 replica2. Does this mean, that we have 4 filter caches, > > i.e. separate memory for each core? If they are separated and for > > example, query1 is handling from coll1 shard1 replica1 and 1 sec later > > the same query is handling from coll2 shard1 replica1, this means, > > that the later query will not use the result set cached from the first > > query... > > That is correct. > > General notes about SolrCloud terminology: SolrCloud is organized around > collections. Collections are made up of one or more shards. Shards are > made up of one or more replicas. Each replica is a Solr core. A core > contains one Lucene index. It is not correct to say that a shard has no > replicas. The leader *is* a replica. If you have a leader and one > follower, the shard has two replicas. > > Solr caches (including filterCache) exist at the core level, they have > no knowledge of other replicas, other shards, or the collection as a > whole. Susheel says that the caches are per host/JVM -- that's not > correct. Every Solr core in a JVM has separate caches, if they are > defined in the configuration for that core. > > Your query scenario has even more separation -- it asks about querying > two completely different collections, which don't use the same cores. > > Thanks, > Shawn > >
