Hi Simon,
By "IndexWriter is threadsafe" do you mean that I can have to two
threads, one calls IndexWriter.addDocument(), the other calls
IndexWriter.deleteDocuments() & IndexWriter.optimize(), without any
synchronization?
For the deadlock, I also think it has something to do with merging.
Below are stacktraces of some of the relevant threads:
"Lucene Merge Thread #2" daemon prio=10 tid=0x086be000 nid=0x4a9
waiting for monitor entry [0x52dad000..0x52dadf20]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.lucene.index.IndexWriter.mergeInit(IndexWriter.java:3964)
- waiting to lock <0x58a745d0> (a org.apache.lucene.index.IndexWriter)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3872)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:205)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:260)
"Lucene Merge Thread #1" daemon prio=10 tid=0x517c3400 nid=0x4a7
waiting for monitor entry [0x52dfe000..0x52dfeea0]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.lucene.index.IndexWriter.mergeInit(IndexWriter.java:3964)
- waiting to lock <0x58a745d0> (a org.apache.lucene.index.IndexWriter)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3872)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:205)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:260)
"Lucene Merge Thread #0" daemon prio=10 tid=0x08714c00 nid=0x4a1
waiting for monitor entry [0x52ff7000..0x52ff7e20]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.lucene.index.IndexWriter.mergeInit(IndexWriter.java:3964)
- waiting to lock <0x58a745d0> (a org.apache.lucene.index.IndexWriter)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3872)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:205)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:260)
"Add Document Thread" prio=10 tid=0x084ef000 nid=0x4985 in
Object.wait() [0x5315c000..0x5315d020]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x58af4548> (a
org.apache.lucene.index.ConcurrentMergeScheduler)
at java.lang.Object.wait(Object.java:485)
at
org.apache.lucene.index.ConcurrentMergeScheduler.merge(ConcurrentMergeScheduler.java:182)
- locked <0x58af4548> (a
org.apache.lucene.index.ConcurrentMergeScheduler)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2402)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2397)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2393)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3443)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1922)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1880)
at
com.patterninsight.indexing.IndexTask.indexDocuments(IndexTask.java:143)
- locked <0x58b422c0> (a org.apache.lucene.index.IndexWriter)
It seems that the last thread has locked the ConcurrentMergeScheduler,
but then wait on it too. Is that the problem?
Chengdu
On Tue, Jul 28, 2009 at 12:28 AM, Simon
Willnauer<simon.willna...@googlemail.com> wrote:
> I can not help you to figure out your exact problem but you can use an
> the same indexwriter instance without synchronization. IndexWriter is
> threadsafe so you synchronized block seems obsolet.
> I could imagine that there is a backgroud merge going on while you try
> to access the critical section ( you synchronized block) which could
> block you code for a while until the merge has finished. Can you
> figure out if a merger-thread is running? The threads name should be
> set to something like "Lucene Merge Thread #n"
>
> simon
>
> On Tue, Jul 28, 2009 at 6:27 AM, Chengdu
> Huang<chengdu.hu...@patterninsight.com> wrote:
>> Hi,
>>
>> I have an application in which documents are added upon receiving a
>> user request and a background thread is needed to remove old
>> documents. I have an IndexWriter opened on a Directory that adds
>> documents and commits but never closes. The background thread that
>> removes documents uses the same instance of IndexWriter. So the code
>> looks like
>>
>> // Thread to add document:
>> synchronized(writer) {
>> try {
>> Document doc = new Document();
>> doc.add();
>> ...
>> writer.commit();
>> } catch (Exception e) {
>> writer.rollback();
>> }
>> }
>>
>> Now looks like I run into some kind of deadlock here even *WITHOUT*
>> the background thread of removing documents. The symptom is that the
>> whole java process is on sleeping state and jstack shows that the
>> thread to add document is blocked on waiting an object. Unfortunately
>> I'm unable to reproduce this in unittests.
>>
>> My guess is that the outer synchronized(writer) {} block is causing
>> the problem, but can't figure out why. Any idea?
>>
>> Chengdu
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
