Shawn, that was a great tip!
When I tried the URL, the core was named as expected
(mycollection_shard1_replica2). I then compared the URLs as reported in the
logs, and I believe I found the bug:
SolrJ: [admin] webapp=null path=/admin/collections params={shard=shard1&
*name=mycollection*&action=ADDREPLICA&*collection=mycollection*
&wt=javabin&version=2}
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"?
Shai
On Mon, Mar 23, 2015 at 6:14 PM, Shawn Heisey <apa...@elyograg.org> wrote:
> On 3/23/2015 9:27 AM, Shai Erera wrote:
> > I have a Solr cluster started (all programmatically) with one Solr node,
> > one collection and one shard. I set the replicationFactor to 1. The name
> of
> > the result core was set to mycollection_shard1_replica1.
> >
> > I then start a second Solr node and issue an ADDREPLICA command as
> > described in the reference guide, using following code:
> >
> > final CollectionAdminRequest.AddReplica addReplicaRequest = new
> > CollectionAdminRequest.AddReplica();
> > addReplicaRequest.setCollectionName("mycollection");
> > addReplicaRequest.setShardName("shard1");
> > final CollectionAdminResponse response =
> > addReplicaRequest.process(solrClient);
> >
> > The replica is added under a core named "mycollection" and not e.g.
> > mycollection_shard1_replica2.
>
> I'd call that a bug.
>
> > BTW, the example in the reference guide shows that issuing the request:
> >
> >
> http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=test2&shard=shard2&node=192.167.1.2:8983_solr
> >
> > Results in
> >
> > <response>
> > <lst name="responseHeader">
> > <int name="status">0</int>
> > <int name="QTime">3764</int>
> > </lst>
> > <lst name="success">
> > <lst>
> > <lst name="responseHeader">
> > <int name="status">0</int>
> > <int name="QTime">3450</int>
> > </lst>
> > * <str name="core">test2_shard2_replica4</str>*
>
> Did you try out a URL like that to see whether it also results in the
> misnamed core, or if it behaves correctly as the reference guide indicates?
>
> If the URL behaves correctly, I'd be curious what Solr logs for the URL
> request and the SolrJ request.
>
> Thanks,
> Shawn
>
>
