[
https://issues.apache.org/jira/browse/LUCENE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579819#action_12579819
]
Michael McCandless commented on LUCENE-1239:
--------------------------------------------
If you replace Compass's ExecutorMergeScheduler with Lucene's
ConcurrentMergeScheduler, does the deadlock still happen?
One thing that makes me nervous about ExecutorMergeScheduler is this comment:
// Compass: No need to execute continous merges, we simply reschedule another
merge, if there is any, using executor manager
and the corresponding change which is to schedule a new job instead of using
the while loop to run new merges. If I understand that code correctly, the
executorManager will re-call the run() method on MergeThread when there is a
cascaded merge. But that won't do the right thing because it will run
"startMerge" rather than the newly returned (cascaded) merge. That would then
cause the deadlock because the cascaded merge is never issued.
> 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]
