On 3/23/2015 10:48 AM, Shai Erera wrote:
> The 'name' param isn't set when I send the URL request (and it's also not
> specified in the reference guide), but only when I add the replica using
> SolrJ. I then tweaked my code to do the following:
>
> final CollectionAdminRequest.AddReplica addReplicaRequest = new
> CollectionAdminRequest.AddReplica() {
> @Override
> public SolrParams getParams() {
> final ModifiableSolrParams params = (ModifiableSolrParams)
> super.getParams();
> params.remove(CoreAdminParams.NAME);
> return params;
> }
> };
>
> And voila, the core is now also named mycollection_shard1_replica2, and I'm
> even able to add as many replicas as I want on this node (where before it
> failed since 'mycollection' already existed).
>
> The 'name' parameter is added by
> CollectionSpecificAdminRequest.getParams(). So how would you suggest to fix
> it:
>
> 1. Remove it in AddReplica.getParams() -- replicas will always be
> auto-named. It makes sense as users didn't have control over it before, and
> maybe they shouldn't.
> 2. Add a setCoreName to AddReplica request -- this would be nice if
> someone wanted to control the name of the added replica, but otherwise
> should not be included in the request
>
> Or maybe we fix the bug by doing #1 and consider #2 as a new feature "allow
> naming replicas"?
Doing both sounds like a good solution to me. I'm trying to think of
some cautionary text for the javadoc on the new method, but I'm not
really sure what it should say. Perhaps something like "when this
method is not used, the new core will receive a name like
collection_shardN_replicaN, be aware that if you override it,
understanding the collection layout may be more difficult."
I'm hoping Mark and/or Yonik (or someone else, if they know) can comment
about why the AddReplica code had that behavior and whether this is a
good idea in the larger SolrCloud environment.
Thanks,
Shawn
