lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Gibney (JIRA)" <>
Subject [jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage
Date Tue, 06 Aug 2019 02:34:00 GMT


Michael Gibney commented on SOLR-13257:

Thanks [~tomasflobbe] and [~cpoerschke] for your feedback, and for helping move this feature
along! I just pushed some commits to address some points raised by [~cpoerschke]: opting
for stricter handling of the {{dividend}} param (if present, it must be an integer), and
adding/clarifying documentation and javadocs.

Most of the changes have to do with added documentation. One functional change was to add
support for the ability to explicitly disable implicit hash-based routing (by setting the
{{hash}} param config to the empty String, in solr.xml). This idea came up as a consequence
of thinking about edge cases while documenting the behavior of replica routing configuration
in solr.xml.

> Enable replica routing affinity for better cache usage
> ------------------------------------------------------
>                 Key: SOLR-13257
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>            Reporter: Michael Gibney
>            Assignee: Tomás Fernández Löbbe
>            Priority: Minor
>         Attachments:, SOLR-13257.patch, SOLR-13257.patch
>          Time Spent: 3h 40m
>  Remaining Estimate: 0h
> For each shard in a distributed request, Solr currently routes each request randomly
via [ShufflingReplicaListTransformer|]
to a particular replica. In setups with replication factor >1, this normally results in
a situation where subsequent requests (which one would hope/expect to leverage cached results
from previous related requests) end up getting routed to a replica that hasn't seen any related
> The problem can be replicated by issuing a relatively expensive query (maybe containing
common terms?). The first request initializes the {{queryResultCache}} on the consulted replicas.
If replication factor >1 and there are a sufficient number of shards, subsequent requests
will likely be routed to at least one replica that _hasn't_ seen the query before. The replicas
with uninitialized caches become a bottleneck, and from the client's perspective, many subsequent
requests appear not to benefit from caching at all.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message