[
https://issues.apache.org/jira/browse/LUCENE-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878397#comment-13878397
]
Simon Willnauer commented on LUCENE-5407:
-----------------------------------------
There is no way this would work here. Your first thread enters the index writer
and gets a threadstate and then once it pulls the fields reader you enter the
indexwriter again to add a "sub-document". This sub-document IW#addDocument
call tries to get a thread-state as well but since there are only 8
ThreadStates by default you run into a deadlock since for the "parent-doc"
thread to make progress the "sub-documents" thread must return from
IW#addDocument but it can't since it waits for another thread to release one of
the ThreadStates. So yes that is a deadlock situation but I really don't see
any way this could work. I guess further this approach is not what I recommend
you do anyways. If you want to index those documents in a stream then I guess a
"producer -> queue -> consumer" approach might be best suited.
> Deadlock? while indexing in cascaded threads
> --------------------------------------------
>
> Key: LUCENE-5407
> URL: https://issues.apache.org/jira/browse/LUCENE-5407
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Affects Versions: 4.6
> Environment: Windows 7 64 bits, JRE 1.7.0_25 64 bits
> Reporter: Luis Filipe Nassif
> Attachments: Test.java, thread_dump.txt
>
>
> Apparently I found a deadlock problem with IndexWriter in a cascaded thread
> design to add documents (I am working on an application integrating Tika,
> which has the capability to add embedded documents to the index as
> independent documents as they are found). The attached code illustrates the
> problem. Sometimes it stops processing, at least one of the threads remains
> in WAITING state. It must be executed no more than 5 times in my environment
> to trigger the problem.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
