It's certainly looks like a bug and the name shouldn't be added to the
request automatically.
Can you confirm what version of Solr are you using?
If it turns out to be a bug in 5x/trunk I'll create a JIRA and fix it to
both #1 and #2.
On Mon, Mar 23, 2015 at 9:48 AM, Shai Erera <ser...@gmail.com> wrote:
> 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
> >
> >
>
--
Anshum Gupta
