[Solr Wiki] Update of "SolrCaching" by YonikSeeley

[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 following page has been changed by YonikSeeley:
http://wiki.apache.org/solr/SolrCaching

------------------------------------------------------------------------------
  
  = Overview =
  
- Solr caches are associated with an Index Searcher — a particular 'view' of the index that doesn't change. So as long as that Index Searcher is being used, the items in the cache will be valid (as long as the cache doesn't get too full) and will be available for reuse. Caching in Solr is unlike ordinary caches in that Solr cached objects will not expire after a certain period of time; rather, cached objects will be valid as long as the Index Searcher is valid.
+ Solr caches are associated with an Index Searcher — a particular 'view' of the index that doesn't change. So as long as that Index Searcher is being used, ant items in the cache will be valid and available for reuse. Caching in Solr is unlike ordinary caches in that Solr cached objects will not expire after a certain period of time; rather, cached objects will be valid as long as the Index Searcher is valid.
  
- The ''current'' Index Searcher serves requests and when a ''new'' searcher is opened, the new one is auto-warmed while the current one is still serving external requests. When the new one is ready, the current one first finishes the requests it is handling, then the system switches to the new, warmed searcher and the current one is discarded. This we call, "registered"—when a searcher becomes the current searcher to handle queries.  The current Searcher is used as the source of auto-warming. When a new searcher is opened, its caches may be prepopulated or "autowarmed" using data from caches in the old searcher. For more information on autowarming and caching, see the Cache Considerations section on the SolrPerformanceFactors page.  
+ The ''current'' Index Searcher serves requests and when a ''new'' searcher is opened, the new one is auto-warmed while the current one is still serving external requests. When the new one is ready, it will be ''registered'' as the ''current'' searcher and will handle any new search requests.  The old searcher will be closed after all request it was servicing finish.   The current Searcher is used as the source of auto-warming. When a new searcher is opened, its caches may be prepopulated or "autowarmed" using data from caches in the old searcher.
  
  There is currently only one cache implementation — solr.search.LRUCache (LRU = Least Recently Used in memory).
   
@@ -21, +21 @@

  
  == autoWarming ==
  
- When a new searcher is opened, its caches may be prepopulated or "autowarmed" with cached object from caches in the old searcher. autowarmCount is the number of cached items that will be copied into the new searcher. You will proably want to base the autowarmCount setting on how long it takes to autowarm. You must consider the trade-off — time-to-autowarm versus how warm (i.e., autowarmCount) you want the cache to be. The autowarm parameter is set for the caches in solrconfig.xml.
+ When a new searcher is opened, its caches may be prepopulated or "autowarmed" with cached object from caches in the old searcher. autowarmCount is the number of cached items that will be regenerated in the new searcher. You will proably want to base the autowarmCount setting on how long it takes to autowarm. You must consider the trade-off — time-to-autowarm versus how warm (i.e., autowarmCount) you want the cache to be. The autowarm parameter is set for the caches in solrconfig.xml.
  
  Below we present the cache-specific parts of the solrconfig.xml file and its recommended settings:
  
@@ -63, +63 @@

  
  == documentCache ==
  
- This cache cannot be used as a source for autowarming Count (autowarmCount="0") because document IDs will change when anything in the index changes so they can't be used by a new searcher.
+ This cache cannot be used as a source for autowarming because document IDs will change when anything in the index changes so they can't be used by a new searcher.
  {{{
      <!-- documentCache caches Lucene Document objects (the stored fields for each document).
        -->
@@ -75, +75 @@

   
  == User/Generic Caches ==
  
- User who have written custom Solr plugins for their applications can configure generic object caches which Solr will maintain and autowarm using whatever regenerator is configured for them.
+ Users who have written custom Solr plugins for their applications can configure generic object caches which Solr will maintain and optionally autowarm if a custom regenerator is specified.
  
  {{{
      <!-- Example of a generic cache.  These caches may be accessed by name
@@ -146, +146 @@

  
  = Tradeoffs =
  
- There will be additional latency due to auto-warming from the time that you request a new searcher to be opened until the time that it becomes "registered". See also the Updates and Commit Frequency section of the SolrPerformanceFactors page for addtional tradeoff considerations. 
+ There will be additional latency due to auto-warming from the time that you request a new searcher to be opened until the time that it becomes "registered".
  
  = Caching and Distribution/Replication =
   
  Distribution/Replication gives you a 'new' index on the slave. When Solr is told to use the new index, the old caches have to be discarded along with the old Index Searcher. That's when autowarming occurs.
  
- If the current Index Searcher is serving requests and when a new searcher is opened, the new one is 'warmed' while the current one is serving external requests. When the new one is ready, the current one first finishes the requests it is handling, then the system switches to the new warmed searcher and the current one is discarded. This we call, "registered", when a searcher becomes the current searcher to handle queries.
+ If the current Index Searcher is serving requests and when a new searcher is opened, the new one is 'warmed' while the current one is serving external requests. When the new one is ready, it is registered so it can serve any new requests while the original one first finishes the requests it is handling. 
   
  = Disabling Caching =