[Solr Wiki] Update of "LotsOfCores" by ErickErickson

[Apache Wiki <wi...@apache.org>]

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.