Configuration makes sense to me, but I don't think we should ever officially support a custom user impl. ...
Okay, that rules out a RecoveryStrategyFactory then, configuration of settings can be done without a factory.
It'd be nice if this could be more clear as to what a "RecoveryStrategy" even is; ...
I agree that the name(s) of any new configuration element(s) need not necessarily match the underlying class names.
RecoveryStrategy currently has three settings which taken literally could translate into configuration something like this:
<recoveryStrategy> <!-- class="solr.RecoveryStrategy" attribute conspicuous by its absence -->
How are the settings used?
... We could perhaps do something like UpdateHandler, where you can do it, but you're crazy to do it unless you check your impl every release and only have minor changes to behavior (and even then it's crazy).
I agree that configuring something other than the defaults is probably a bit of a niche use case. Replication via an alternative network interface (SOLR-9044) e.g. to separate out replication versus regular live within-cloud traffic would perhaps also be relatively niche (though technically only a minor change to behaviour) and opt-in to that could be via an additional configuration rather than a class derived from the existing RecoveryStrategy class.
So, it seems there's three alternatives.
- solrconfig.xml element called <recoveryStrategy> similar to the <updateHandler> element and as illustrated above
- solrconfig.xml element(s) called something else (similar to the <updateHandler> element?)
- two additional system properties "solr.cloud.max-retries" and "solr.cloud.starting-recovery-delay" ("solr.cloud.wait-for-updates-with-stale-state-pause" already exists)
What do you think?