[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org