Jerry, This is why people often do index modifications on one server (master) and replicate the read-only index to 1+ different servers (slaves). If you do that, does the problem go away?
Otis ---- Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Hadoop ecosystem search :: http://search-hadoop.com/ ----- Original Message ---- > From: Jerome L Quinn <jlqu...@us.ibm.com> > To: solr-user@lucene.apache.org > Sent: Fri, March 5, 2010 10:13:03 AM > Subject: Re: SolrJ commit options > > Shalin Shekhar Mangar wrote on 02/25/2010 07:38:39 > AM: > > > On Thu, Feb 25, 2010 at 5:34 PM, gunjan_versata > wrote: > > > > > > > > We are using SolrJ to handle commits to our solr server.. All runs > fine.. > > > But whenever the commit happens, the server becomes slow and stops > > > responding.. therby resulting in TimeOut errors on our production. We > are > > > using the default commit with waitFlush = true, waitSearcher = true... > > > > > > Can I change there values so that the requests coming to solr dont > block on > > > recent commit?? Also, what will be the impact of changing these > values?? > > > > > > > Solr does not block reads during a commit/optimize. Write operations are > > queued up but they are still accepted. Are you using the same Solr server > > for reads as well as writes? > > I've seen similar things with Solr 1.3 (not using SolrJ). If I try to > optimize the > index, queries will take much longer - easily a minute or more, resulting > in timeouts. > > Jerry