lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Complete discussion of Solr "cores" ? (beyond wiki?)
Date Tue, 30 Jun 2009 18:06:57 GMT

: Date: Mon, 1 Jun 2009 10:33:50 -0700
: From: Mark Bennett
: Subject: Complete discussion of Solr "cores" ? (beyond wiki?)

Mark: catching up on my mail, i don't see much discussion arround your 
various questions.

: However, even after re-reading the wiki entries, I'm still not clear what is
: meant by "core".  The info I find talks about administering multiple cores,

I've attempted to clarify that a bit by adding an entry to the terminology 

>> Solr Core: Also referred to as just a "Core" This is a running instance 
>> of a Solr index along with all of it's configuration (SolrConfigXml, 
>> SchemaXml, etc...). A single Solr application can contain 0 or more 
>> cores which are run largely in isolation but can communicate with each 
>> other if necessary via the CoreContainer. From a historical 
>> perspective: Solr initially only supported one index, and the SolrCore 
>> class was a singleton for coordinating the low level functionality at 
>> the "core" of Solr. When support was added for creating and managing 
>> multiple Cores on the fly, the class was refactored to no longer be a 
>> Singleton, but the name stuck. 

: But, for example, is an instance directory with a valid solrconfig.xml and
: schema.xml a valid singular core?  Or do you then need to register a core

An instanceDir is neccessary to create a SolrCore, but a SolrCore is a 
running java object that manages access to an index (via request handlers, 
and field types etc...) based on those configs.

: with an arbitrary name?  For example, getCoreNames() gives an empty array,
: even after it's loaded a valid instance dir / config / schema.

...hmmm. can you give us a more concrete example of how you are seeing 
this.  (code, configs, etc...).  That may be the expected situation when 
running in the legacy "single core" mode (ie: no solr.xml file) but i'm 
not 100% certain.

: And does a core REQUIRE a process to come up on a port, even for an instant,
: or can you do some quick tests from the command line with a "static" core
: and not need to bind to a port?

: And can search operations be done "statically", without the use of TCP/IP
: port, like Lucene can?  Do cores support this?

a Solr Core is really a java run time concept .. typically Solr Cores 
existing the Solr app -- which is a webapp, living in a servlet container, 
running on a part -- but any java program can use a CoreContainer to bring 
up a SolrCore if it wants to (this would be known as Embedded Solr)

: And when moving from a single to multi core, how much extra configuration is
: needed?  On the one extreme, do multiple cores require a completely separate
: instance dir, data dir and solrconfig?  Or on the other end of the spectrum,

again it depends on wether you are talking about the Solr application, or 
about embedding SOlr is another applicaiton.  In the Solr app you need a 
solr.xml file containing info about the multiple cores you want to run, or 
at least indicating that you want to run multiple cores and then you can 
create them at run time using the CoreAdmin commands. 

if you embed solr then you can declare cores progromaticly in java.

as for wether you need seperate instanceDir, data dir, and solrconfig ... 
you definitely need seperate datadirs, but you can get away with reusing 
the same config files if you actuall ywant the SolrCores to all have 
identical configs -- if you wnat them to be different, they need to be 
different (obviously)


View raw message