I think we should deprecate it. There were some concerns about this because new users would understand quickly what "replicationFactor" is, while "nrtReplicas" is not so intuitive, but I don't like having two ways to do the same, and now that there are multiple types of replicas I think it's better for the parameter to be explicit. I would still keep accepting the parameter for backwards compatibility, but maybe remove the internal use of it? Maybe even remove it from the clusterstate (and again, make sure we can still read cluster states that have it, for upgrades).
On Thu, Jun 14, 2018 at 2:46 PM, Varun Thacker <[email protected]> wrote: > While working on SOLR-11676 > <https://issues.apache.org/jira/browse/SOLR-11676> a few questions came > that were't obvious > > Should a user be allowed to specify replicationFactor and nrtReplicas ? > Today it's possible but my answer was it shouldn't be. What do others > think? > > If everyone agrees the two shouldn't be specified then there is one > problem while fixing this - SolrJ > > if (nrtReplicas != null) { > params.set( ZkStateReader.REPLICATION_FACTOR, nrtReplicas);// Keep both for > compatibility? > params.set( ZkStateReader.NRT_REPLICAS, nrtReplicas); > } > > SolrJ sets both replicationFactor and nrtReplicas with the same value. So if > we simply put a check at the server saying "don't allow both parameters" all > SolrJ calls from older clients will fail > > The compromise would be the server could check if both nrtReplicas and > replicationFactor are equal then don't error out > > > Second question, SolrJ doesn't allow a user to specify replicationFactor but > if you're using the API directly it's allowed. > > Do we plan on deprecating replicationFactor eventually in favour of > nrtReplicas ? If yes would 7.5 be a good place to start throwing a warning ? > > >
