Unfortunately, (I think?) Solr currently commits by closing the IndexWriter, which must wait for any running merges to complete, and then opening a new one.
This is really rather silly because IndexWriter has had its own commit method (which does not block ongoing indexing nor merging) for quite some time now. I'm not sure why we haven't switched over already... there must be some trickiness involved. Mike On Thu, Dec 16, 2010 at 9:39 AM, Renaud Delbru <renaud.del...@deri.org> wrote: > Hi, > > See log at [1]. > We are using the latest snapshot of lucene_branch3.1. We have configured > Solr to use the ConcurrentMergeScheduler: > <mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/> > > When a commit() runs, it blocks indexing (all imcoming update requests are > blocked until the commit operation is finished) ... at the end of the log we > notice a 4 minute gap during which none of the solr cients trying to add > data receive any attention. > This is a bit annoying as it leads to timeout exception on the client side. > Here, the commit time is only 4 minutes, but it can be larger if there are > merges of large segments > I thought Solr was able to handle commits and updates at the same time: the > commit operation should be done in the background, and the server still > continue to receive update requests (maybe at a slower rate than normal). > But it looks like it is not the case. Is it a normal behaviour ? > > [1] http://pastebin.com/KPkusyVb > > Regards > -- > Renaud Delbru >
