Either of them works for me. If you want to get your hands dirty, please go
ahead.
I can review/provide feedback if you need anything there. I'll just create
a JIRA to begin with.
On Tue, Mar 24, 2015 at 9:15 AM, Shai Erera <ser...@gmail.com> wrote:
> I use vanilla 5.0. I intended to fix it myself, but if you want to go
> ahead, I'd be happy to review the patch.
>
> Shai
>
> On Tue, Mar 24, 2015 at 6:11 PM, Anshum Gupta <ans...@anshumgupta.net>
> wrote:
>
> > 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
> >
>
--
Anshum Gupta
