Hi Michael,
thanks for your answer.
Do the Solr team is aware of the problem ? Is there an issue opened
about this, or ongoing work about that ?
Regards,
--
Renaud Delbru
On 16/12/10 16:45, Michael McCandless wrote:
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
