: 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
