[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562707#comment-14562707
]
Robert Muir commented on LUCENE-6507:
-------------------------------------
I disagree with the synopsis. The problem here has nothing to do with Directory
or the lock API at all... this is all bugs in NativeFSLockFactory, around this
behavior in the JDK:
{noformat}
On some systems, closing a channel releases all locks held by the Java virtual
machine on the underlying file regardless of whether the locks were acquired
via that channel or via another channel open on the same file. It is strongly
recommended that, within a program, a unique channel be used to acquire all
locks on any given file.
{noformat}
-1 to changing the Directory/lock API, when it will not even fix the problem:
even attempting to obtain() means you are screwed.
To me the correct solution is to fix NativeFSLockFactory to follow the "strong
recommendations". Today it already has a global map to try to workaround issues:
{code}
private static final Set<String> LOCK_HELD = Collections.synchronizedSet(new
HashSet<String>());
{code}
Seems that this is wrong, and needs to be a map with unique file channels as
the 'value'.
> Directory#makeLock is trappy
> ----------------------------
>
> Key: LUCENE-6507
> URL: https://issues.apache.org/jira/browse/LUCENE-6507
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Simon Willnauer
>
> the lock API in Lucene is super trappy since the lock that we return form
> this API must first be obtained and if we can't obtain it the lock should not
> be closed since we might ie. close the underlying channel in the NativeLock
> case which releases all lock for this file on some operating systems. I think
> the makeLock method should try to obtain and only return a lock if we
> successfully obtained it. Not sure if it's possible everywhere but we should
> at least make the documentation clear here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
