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

Reply via email to