[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14563896#comment-14563896
]
Mark Miller commented on LUCENE-6507:
-------------------------------------
I'll lend a hand and spell it out.
Anshum asked if I'd look at this issue as it involves hdfs and the release.
I looked at it. I found that:
bq. Just a change in API behavior. Previously a double obtain was returning
false and now it's throwing an exception.
This is true. I don't care how smart you think you are.
By then, Robert had made a further commit.
Beyond that, not much to see here. Chill out.
> NativeFSLock.close() can invalidate other locks
> -----------------------------------------------
>
> Key: LUCENE-6507
> URL: https://issues.apache.org/jira/browse/LUCENE-6507
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Simon Willnauer
> Priority: Blocker
> Fix For: 4.10.5, 5.2
>
> Attachments: LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch,
> LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch,
> LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch, LUCENE-6507.patch
>
>
> 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]
