lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "LotsOfCores" by ErickErickson
Date Thu, 14 Feb 2013 12:45:15 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "LotsOfCores" page has been changed by ErickErickson:
http://wiki.apache.org/solr/LotsOfCores?action=diff&rev1=22&rev2=23

   * Changes to SolrJ for new start/stop commands and better error codes/messages.
  
  = Configuration =
- As I'm digging into this, things are changing. What follows is fluid, it may change as this
progresses. Much of this work will show the most benefit if there is a custom CoreDescriptorProvider
in the chain.
+ As I'm digging into this, things are changing. What follows is fluid, it may change as this
progresses.
  
  There are two new attributes of a <core> tag (defaults in bold) and one new attribute
for <cores>
   * <cores> has a two new attributes:
    * transientCacheSize=[NNN]. If this limit is crossed, old cores marked 'transient="true"'
are removed to make room on an LRU basis. 
     * If this is absent, the default is Integer.MAX_VALUE, an unbounded cache. ''Only'' cores
with "transient=true" are put in this cache, so specifying this attribute without having any
cores marked as "transient" has no effect, just wastes a LinkedHashMap<String, SolrCore>
of the specified size which will never be used.
     * Having this size be less than the number of cores marked 'transient="true"' AND 'loadOnStartup="true"'
''should'' work, but it's wasteful since a bunch of cores will be loaded on startup then immediately
unloaded after the cache fills up.
-    * NOTE: when solr.xml is read, the information for all transient cores (i.e. the CoreDescriptor)
is put in a separate list. So having more transient cores than the size of the cache will
be handled correctly. The "list of cores" is unbounded.
+    * NOTE: when solr.xml is read, the information for all transient cores is put in a separate
list. So having more transient cores than the size of the cache will be handled correctly.
The "list of cores" is unbounded. 
-   * coreDescriptorProvider=<class derived from CoreDescriptorProvider>. (more later,
this isn't done yet). This will be a pluggable component that provides a CoreDescriptor on
demand. Solr core handling will ask this component (if present) for a CoreDescriptor for any
core name it doesn't recognize. If the component returns a CoreDescriptor, it will be added
to the appropriate internal list based on the values of the loadOnStartup and transient member
variables. The code will ''probably'' load the core no matter what the loadOnStartup parameter
specifies on the theory that there is an immediate request to be satisfied. TBD. 
   * <core> has two new attributes:
    * loadOnStartup=["'''true'''"|"false"]. Whether the core should be completely loaded upon
startup.
    * transient=["true"|"'''false'''"]. Whether the core is allowed to be swapped out or not.
@@ -77, +76 @@

  }}}
  
  == Persistence ==
- This is a sticky wicket. As currently written, the Solr.xml file has a global 'persist="true|false"'
option. The base problem is maintenance. What I'm currently thinking is that Solr should ''only''
persist cores that were originally defined in solr.xml and should ''not'' persist any core
that was provided by the CoreDescriptorProvider.
+ This is a sticky wicket. As currently written, the Solr.xml file has a global 'persist="true|false"'
option. The base problem is maintenance. 
  
  == From the original page, under discussion ==
   * START/STOP commands. Actually, it doesn't seem like there's anything that could be done
with these that isn't accomplished by CREATE/UNLOAD. Perhaps alias START->CREATE and STOP->UNLOAD
with suitable defaults? I.e. STOP would never delete the index.

Mime
View raw message