: 1) Any recommendations on which best to sub-class? I'm guessing, for this : scenario with "rare" batch puts and no evictions, I'd be looking for get : performance. This will also be on a box with many CPUs - so I wonder if the : older LRUCache would be preferable?
i suspect you are correct ... the entire point of the other caches is dealingwith faster replacement, so you really don't care. You might even find it worth while to write your own "NoReplacementCache" from scratch backed by a HashMap (instead of the LinkedHashMap used in LRUCache) : 2) Would I need to worry about "auto warming" at all? I'm still a little : foggy on lifecycle of firstSearcher versus newSearcher (is firstSearcher : really only ever called the first time the solr instanced is started?). In essentially correct - technically it's when the SolrCore is created (which may not be exactly when the solr instance is started). it's when the "first searcher" is created for the SolrCore, and there is no other previous searcher. : any case, since the only time a commit would occur is when batch updates, : re-indexing and re-optimizing occurs (once a day off-peak perhaps) I : *think* I would always want to perform the same "static warming" rather : than attempting to auto-warm from the old cache - does this make sense? auto-warming should be faster then any static warming you could do, because the existing Query objects will already be in memory, no loading/parsing required. That said: if you expect/want the list of queries to be evolvable (ie: add or remove a few queries w/o restarting / reloading the SolrCore) then you're correct: better to use static warming in newSearcher and skip autowarming completley -- but for your usecase you shouldn't need both. -Hoss
