You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Tom Burton-West <tb...@umich.edu> on 2014/02/05 21:34:37 UTC
Default core for updates in multicore setup
Hello,
I'm running the example setup for Solr 4.6.1.
In the ../example/solr/ directory, I set up a second core. I wanted to
send updates to that core.
I looked at .../exampledocs/post.sh and expected to see the URL as: URL=
http://localhost:8983/solr/collection1/update
However it does not have the core name:
URL=http://localhost:8983/solr/update
Solr however accepts updates with that url in the core named collection1.
I then tried to locate some config somewhere that would specify that the
default core would be collection1, but could not find it.
1) Is there somewhere where the default core for the xx/solr/update URL is
configured?
2) I ran across SOLR-545 which seems to imply that the current behavior
(dispatching the update requests to the core named collection1) is a bug
which was fixed in Solr 1.3. Is this a new bug or a change in design?
https://issues.apache.org/jira/browse/SOLR-545
Tom
Re: Default core for updates in multicore setup
Posted by Jack Krupansky <ja...@basetechnology.com>.
Tom, I did make an effort to "sort out" both the old and newer solr.xml
features in my Solr 4.x Deep Dive e-book.
-- Jack Krupansky
-----Original Message-----
From: Tom Burton-West
Sent: Wednesday, February 5, 2014 5:56 PM
To: solr-user@lucene.apache.org
Subject: Re: Default core for updates in multicore setup
Thanks Hoss,
>>hardcoded default of "collection1" is still used for
backcompat when there is no "defaultCoreName" configured by the user.
Aha, it's hardcoded if there is nothing set in a config. No wonder I
couldn't find it by grepping around the config files.
I'm still trying to sort out the old and new style solr.xml/core
configuration stuff. Thanks for your help.
Tom
On Wed, Feb 5, 2014 at 4:31 PM, Chris Hostetter
<ho...@fucit.org>wrote:
>
> : I then tried to locate some config somewhere that would specify that the
> : default core would be collection1, but could not find it.
>
> in the older style solr.xml, you can specify a "defaultCoreName". Moving
> forward, relying on the default core name is discouraged (and will
> hopefully be removed before 5.0) so it's not possible to configure it in
> the new core discovry style of solr.xml...
>
> https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
>
> For now owever, the hardcoded default of "collection1" is still used for
> backcompat when there is no "defaultCoreName" configured by the user.
> and things like post.sh, post.jar, and the tutorial have not really been
> updated yet to reflect that the use of the default core name is
> deprecated.
>
> : 2) I ran across SOLR-545 which seems to imply that the current behavior
> : (dispatching the update requests to the core named collection1) is a bug
>
> Yeah, A lot of things have changed since 1.3 ... not sure when exactly the
> configurable defaultCoreName was added, but it was sometime after that
> issue i believe.
>
>
> -Hoss
> http://www.lucidworks.com/
>
Re: Default core for updates in multicore setup
Posted by Tom Burton-West <tb...@umich.edu>.
Thanks Hoss,
>>hardcoded default of "collection1" is still used for
backcompat when there is no "defaultCoreName" configured by the user.
Aha, it's hardcoded if there is nothing set in a config. No wonder I
couldn't find it by grepping around the config files.
I'm still trying to sort out the old and new style solr.xml/core
configuration stuff. Thanks for your help.
Tom
On Wed, Feb 5, 2014 at 4:31 PM, Chris Hostetter <ho...@fucit.org>wrote:
>
> : I then tried to locate some config somewhere that would specify that the
> : default core would be collection1, but could not find it.
>
> in the older style solr.xml, you can specify a "defaultCoreName". Moving
> forward, relying on the default core name is discouraged (and will
> hopefully be removed before 5.0) so it's not possible to configure it in
> the new core discovry style of solr.xml...
>
> https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
>
> For now owever, the hardcoded default of "collection1" is still used for
> backcompat when there is no "defaultCoreName" configured by the user.
> and things like post.sh, post.jar, and the tutorial have not really been
> updated yet to reflect that the use of the default core name is
> deprecated.
>
> : 2) I ran across SOLR-545 which seems to imply that the current behavior
> : (dispatching the update requests to the core named collection1) is a bug
>
> Yeah, A lot of things have changed since 1.3 ... not sure when exactly the
> configurable defaultCoreName was added, but it was sometime after that
> issue i believe.
>
>
> -Hoss
> http://www.lucidworks.com/
>
Re: Default core for updates in multicore setup
Posted by Chris Hostetter <ho...@fucit.org>.
: I then tried to locate some config somewhere that would specify that the
: default core would be collection1, but could not find it.
in the older style solr.xml, you can specify a "defaultCoreName". Moving
forward, relying on the default core name is discouraged (and will
hopefully be removed before 5.0) so it's not possible to configure it in
the new core discovry style of solr.xml...
https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
For now owever, the hardcoded default of "collection1" is still used for
backcompat when there is no "defaultCoreName" configured by the user.
and things like post.sh, post.jar, and the tutorial have not really been
updated yet to reflect that the use of the default core name is
deprecated.
: 2) I ran across SOLR-545 which seems to imply that the current behavior
: (dispatching the update requests to the core named collection1) is a bug
Yeah, A lot of things have changed since 1.3 ... not sure when exactly the
configurable defaultCoreName was added, but it was sometime after that
issue i believe.
-Hoss
http://www.lucidworks.com/