[
https://issues.apache.org/jira/browse/LUCENE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573664#comment-13573664
]
i30817 commented on LUCENE-4760:
--------------------------------
TBH i have no idea why it 'works' of even if there is not dozens of hidden bugs
there. IMO, close() should release the filelocks the writer acquired, if they
are all internal like currently; or not at all, if there are external ones
(like IndexSearch has). So if you're currently considering the interruptibility
of close, or whether it should commit or not, all i ask is that it
'invalidates' the underlying resources usage so native/other locks get released
if it is interrupted or not; if it was actually called.
> Weird IndexWriter.close() usage
> -------------------------------
>
> Key: LUCENE-4760
> URL: https://issues.apache.org/jira/browse/LUCENE-4760
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.1
> Reporter: i30817
> Priority: Minor
>
> I'm using IndexWriter on such a way that it can be interrupted, since the
> streams i'm using to output to file can be interrupted. So far so good, but
> what i'm finding strange is the (only) way i've found to prevent the file
> lock being held afterwards.
> Normally i'd do a try / catch / finally block where the finally would close()
> and handle exceptions from the close. However, IndexWriter "close()" is more
> like a buffered commit, where many exceptions can occur, so i left it on the
> main part of the code.
> try{... index.close(); } catch { /*log*/ } finally {
> if (IndexWriter.isLocked(cacheDir)) {
> IndexWriter.unlock(cacheDir);
> }
> }
> Didn't work. The lock couldn't be unlocked (always) if the stream was
> interrupted
> So in desperation, i tried to be more literal in my interpretation of the
> IndexWriter.close() javadoc and tried
> try {
> ...
> indexWriter.close();
> } catch (IOException ex) {
> try {
> indexWriter.close();
> } finally {
> if (IndexWriter.isLocked(cacheDir)) {
> IndexWriter.unlock(cacheDir);
> }
> }
> throw ex;
> } finally {
> ...
> }
> This worked (the lock was always released if a additional close() was invoked
> in a situation where the lock would be held before trying to unlock it), but
> i find it really counter-intuitive, and would wish for at least additional
> javadoc attention, or a redesign on a major API revision.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
