You didn't mention it by name, but it sounds like you're talking about the v1 API's "replicationFactor" parameter (which has defaulted to creating NRT replicas for awhile now)?
Personally, I'd rather see that parameter (and corresponding SolrJ code) go away altogether. Some things (e.g. the configset name, the number of shards) are important enough that we force users to be explicit about them...IMO the number and type of replicas fall into that category. But while the ambiguous "replicationFactor" parameter exists I think some sort of "default replica type" concept makes sense. (Granted that we find a way to handle certain complications, like how "PULL" replicas *must* be used in conjunction with replicas of other leader-eligible replica types.) On Wed, May 1, 2024 at 2:32 PM David Smiley <dsmi...@apache.org> wrote: > > In the interests of supporting different replica types better, I'd > like our SolrJ CollectionAdminRequest methods to not *locally* assume > NRT when creating a request. Calls like createCollection(collection > name, numShards, numReplicas) are nicely ambiguous as to the type, nor > do javadocs indicate what the type is. This is good, I think. Yet > the default behavior is to create a v1 API call that specifies how > many NRT replicas (yes of this specific type) to make. Instead, I'd > like to see the replica type decision made by the server (Solr). > Today it also assumes NRT but I could imagine something as simple as > EnvUtils (env var / sys prop) deciding what the default type should > be. So far this is merely changing CollectionAdminRequest and > consequently the specificity of its v1 requests. It'd be followed up > by improving a number of tests to be less specific to NRT. Any > concerns here? > > *Actually* using other replica types (like TLOG or ZERO) may raise > issues for some tests beyond this, sure. In particular, many tests > assume read-your-write (index, commit, query --> find it) but this > won't hold if the query randomly routes to a non-leader. For this I'm > thinking an automatically applied > shards.preference=replica.leader:true > https://solr.apache.org/guide/solr/latest/deployment-guide/solrcloud-distributed-requests.html#shards-preference-parameter > -- only when the default replica type isn't NRT. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
