On 8/4/2014 9:08 AM, Simo Simov wrote: > > SolrCache implementations LRUCache, FastLRUCache and LFUCache have a > parameter initialSize, that is passed directly to HashMap > initialCapacity constructor argument. > > For LFUCache this is the code line: > > map = new LinkedHashMap<K,V>(initialSize, 0.75f, true) … > > In solrconfig.xml I tried to set initialSize to be size/0.75 + > some_more, but it’s impossible to set value greather than size because > of this line: > > final int initialSize = Math.min(str==null ? 1024 : > Integer.parseInt(str), limit); > > For FastLRUCache there is no such limitation, but still I think > documentation and default values in solrconfig.xml should not use > equal values for initialSize and size. >
Simo, I wrote LFUCache, with FastLRUCache as a model. I'm having a hard time grasping exactly what you've written above, which is probably my failing. Based on what I think I understand, here's what I can say: This is the line I can find in LFUCache.java that's similar (but not the same) as the line you mentioned. The actual line you mentioned is in LRUCache, not LFUCache: final int initialSize = str == null ? limit : Integer.parseInt(str); The initialSize value should never be greater than size, but that line will not prevent you from setting it larger -- it only determines what happens if the initialSize parameter is missing from the config, which is to set it the same as size. I believe this is the correct action. The similar line in LRUCache (the one that you quoted) could produce unexpected behavior, because if initialSize is missing, it will be limited to 1024, even if size is many times larger than that. The workaround is to explicitly set initialSize, so I don't think it's actually a bug. Setting initialSize and size to the same value is a perfectly acceptable and logical thing to do. You're telling Solr that it should allocate all of the slots in the underlying Collection object up front, so it won't be forced to dynamically expand it later -- an operation that could take time. On a related front, I actually would like to completely replace the LFUCache implementation with a new one, because the current implementation is a very naive and unoptimized way of doing LFU.I just haven't found time to work on it. See SOLR-2906 and SOLR-3393. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
