Why do you care? Curiosity or are you trying to find a behavior you can count on?
because "soft commits are about visibility, hard commits are about durability". Meaning you can't count on a soft commit writing anything to disk at all. I suspect in your tests the soft commit had nothing to do with the changes on disk, those were just a consequence of indexing more data triggering a flush to disk and would have happened if you hadn't done a soft commit. hard commits are what you can control writes to disk with, not soft commits. Best, Erick On Tue, Sep 24, 2013 at 3:56 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 9/24/2013 5:51 AM, adfel70 wrote: >> >> My conclusion is that soft commit always flushes the data, but because of >> the implementation of NRTCachingDirectoryFactory, the data will be written >> to the disk when its getting too big. > > > The NRTCachingDirectoryFactory (which creates NRTCachingDirectory instances) > used by default in newer Solr versions has default settings for some of its > parameters that show up in the solr log: > > maxCacheMB=48.0 maxMergeSizeMB=4.0 > > The constructor javadocs for NRTCachingDirectory show what circumstances > will cause the directory to use RAM instead of flushing to disk: > > http://lucene.apache.org/core/4_4_0/core/org/apache/lucene/store/NRTCachingDirectory.html#NRTCachingDirectory%28org.apache.lucene.store.Directory,%20double,%20double%29 > > "We will cache a newly created output if 1) it's a flush or a merge and the > estimated size of the merged segment is <= maxMergeSizeMB, and 2) the total > cached bytes is <= maxCachedMB" > > Thanks, > Shawn >
