[
https://issues.apache.org/jira/browse/LUCENE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579909#action_12579909
]
Michael McCandless commented on LUCENE-1239:
--------------------------------------------
{quote}
I wondered if there is a chance that the current scheduler can be enhanced to
support an extension point for that... . I can give such a refactoring a go if
you think it make sense.
{quote}
That would be much appreciated! You should start from the trunk version of
CMS: it already has been somewhat factored to allow subclasses to override
things, though I think maybe not quite enough for this case.
> IndexWriter deadlock when using ConcurrentMergeScheduler
> --------------------------------------------------------
>
> Key: LUCENE-1239
> URL: https://issues.apache.org/jira/browse/LUCENE-1239
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.3.1
> Environment: Compass 2.0.0M3 (nightly build #57), Lucene 2.3.1,
> Spring Framework 2.0.7.0
> Reporter: Michael Lossos
> Assignee: Michael McCandless
>
> I'm trying to update our application from Compass 2.0.0M1 with Lucene 2.2 to
> Compass 2.0.0M3 (latest build) with Lucene 2.3.1. I'm holding all other
> things constant and only changing the Compass and Lucene jars. I'm recreating
> the search index for our data and seeing deadlock in Lucene's IndexWriter. It
> appears to be waiting on a signal from the merge thread. I've tried creating
> a simple reproduction case for this but to no avail.
> Doing the exact same steps with Compass 2.0.0M1 and Lucene 2.2 has no
> problems and recreates our search index. That is to say, it's not our code.
> In particular, the main thread performing the commit (Lucene document save)
> from Compass is calling Lucene's IndexWriter.optimize(). We're using
> Compass's ExecutorMergeScheduler to handle the merging, and it is calling
> IndexWriter.merge(). The main thread in IndexWriter.optimize() enters the
> wait() at the bottom of that method and is never notified. I can't tell if
> this is because optimizeMergesPending() is returning true incorrectly, or if
> IndexWriter.merge()'s notifyAll() is being called prematurely. Looking at the
> code, it doesn't seem possible for IndexWriter.optimize() to be waiting and
> miss a notifyAll(), and Lucene's IndexWriter.merge() was recently fixed to
> always call notifyAll() even on exceptions -- that is all the relevant
> IndexWriter code looks properly synchronized. Nevertheless, I'm seeing the
> deadlock behavior described, and it's reproducible using our app and our test
> data set.
> Could someone familiar with IndexWriter's synchronization code take another
> look at it? I'm sorry that I can't give you a simple reproduction test case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
