Maybe autoCommit is a good option for you. In other words, don't let your clients issue commits - have Solr commit every N docs or every N minutes/hours.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Sébastien Rainville <[EMAIL PROTECTED]> > To: solr-user <solr-user@lucene.apache.org> > Sent: Friday, June 20, 2008 5:06:46 PM > Subject: Reasonable number of updates before a commit > > Hi, > > Is there a rule of thumb for the maximum number of updates before issuing a > commit? > > For example, I'm using a MapReduce job for indexing a table in HBase... but > the problem is that I can't just let the reducers commit whenever they want > or else commits tend to happen at the same time and therefore resulting in > exceeding the maximum number of searchers warmed at the same time. On the > other hand, I can't imagine updating let's say 2 000 000 records in the > index in a distributed manner and issuing a commit only at the end... > > Sebastien
