: I have autocommit turned completely off -- both values set to zero. The DIH ... : When I first set this up back on 1.4.1, I had some kind of severe problem when : autocommit was turned on. I can no longer remember what it caused, but it was : a huge showstopper of some kind.
the key question about using autocommit is wether or not you use "openSearcher" with it and wether you have the updateLog turned on. as i understand it: if you don't care about real time get, or transaction recovery of "uncommited documents" on hard crash, or any of the Solr Coud features, then you don't need the updateLog -- and you shouldn't add it to your existing configs when upgrading to Solr4. any existing usage (or non-usage) you had of autocommit should continue to work fine. If you *do* care about things that require the updateLog, then you want to ensure that you are doing "hard commits" (ie: perisisting the index to disk) relatively frequently in order to keep the size of the updateLog from growing w/o bound -- but in Solr 4, doing a hard commit no longer requires that you open a new searcher. opening a new searcher and dealing with the cache loading is one of the main reasons people typically avoided autoCommit in the past. So if you look at the Solr 4 example: it uses the updateLog combined with a 15 second autoCommit that has openSearcher=false -- meaning that the autocommit logic is ensuring that anytime the index has modifications they are written to disk every 15 seconds, but the new documents aren't exposed to search clients as a result of those autocommits, and if a client uses real time get, or if there is a a hard crash, the uncommited docs are still available in the udpateLog. For your usecase and upgrade: don't add the updateLog to your configs, and don't add autocommit to your configs, and things should work fine. if you decide you wnat to start using something that requires the updateLog, you should probably add a short autoCommit with openSearcher=false. -Hoss