[
https://issues.apache.org/jira/browse/LUCENE-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789894#action_12789894
]
Shai Erera commented on LUCENE-2104:
------------------------------------
Thanks for the comments. I proposed this above:
bq. perhaps the fix should be to add an unlock() method to Lock and impl it in
SimpleFSLock by calling release(), but on NativeFSLock to first obtain the lock
and if that succeeds, release it. That way, the obtain would fail and we can
throw an exception. Also, we can keep release() and impl in NativeFSLock to
first obtain if it does not hold the lock.
I vote for the second option (i.e. not adding another API, but use what's there
and include a "first obtain then release" logic in an 'else' part in
NativeFSLock).
> IndexWriter.unlock does does nothing if NativeFSLockFactory is used
> -------------------------------------------------------------------
>
> Key: LUCENE-2104
> URL: https://issues.apache.org/jira/browse/LUCENE-2104
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Shai Erera
> Fix For: 3.1
>
> Attachments: LUCENE-2104.patch
>
>
> If NativeFSLockFactory is used, IndexWriter.unlock will return, silently
> doing nothing. The reason is that NativeFSLockFactory's makeLock always
> creates a new NativeFSLock. NativeFSLock's release first checks if its lock
> is not null. However, only if obtain() is called, that lock is not null. So
> release actually does nothing, and so IndexWriter.unlock does not delete the
> lock, or fail w/ exception.
> This is only a problem in NativeFSLock, and not in other Lock
> implementations, at least as I was able to see.
> Need to think first how to reproduce in a test, and then fix it. I'll work on
> it.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
