[
https://issues.apache.org/jira/browse/LUCENE-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045819#comment-13045819
]
Adam Ahmed commented on LUCENE-91:
----------------------------------
A colleague just noticed that the timeout isn't native. That is, by default
Lucene will attempt to create the lock once, but won't actually "timeout"
because it uses tryLock(). So the problem is not Lucene (since it's guaranteed
to give you at least one fair shot, even on a slow FS), but that the lock is
already held.
So this goes back to being decidedly not-a-bug. Apologies.
> IndexWriter ctor does not release lock on exception
> ---------------------------------------------------
>
> Key: LUCENE-91
> URL: https://issues.apache.org/jira/browse/LUCENE-91
> Project: Lucene - Java
> Issue Type: Bug
> Components: core/index
> Affects Versions: 1.2
> Environment: Operating System: All
> Platform: All
> Reporter: Alex Staubo
> Assignee: Lucene Developers
>
> If IndexWriter construction fails with an exception, the write.lock lock is
> not
> released.
> For example, this happens if one tries to open an IndexWriter on an
> FSDirectory
> which does not contain an Lucene index. FileNotFoundException will be thrown
> by
> org.apache.lucene.store.FSInputStream, after which the write lock will remain
> in
> the directory, and nobody can open the index.
> I have been using this pattern -- doing IndexWriter(..., false), catching
> FileNotFoundException and doing IndexWriter(..., true) -- in my code to
> initialize the index on demand, because the app never know if the index
> already
> exists.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
