[ 
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-6507:
---------------------------------------
    Attachment: LUCENE-6507-410x.patch

So ... here's a 4.10.x backport patch, but it was kinda messy: lots of
conflicts because we've basically already rewritten locking once in 5.x.

I stuck with java.io APIs (File) instead of converting to NIO.2 apis
(Path).  I also back-ported AssertingLock to MockDirectoryWrapper.

This patch breaks NativeFSLockFactory.clearLock: its impl "relied" on
this "when I close I nuke any other locks" behavior, and I had to
remove one test case that in facets module that was doing this.  The
API is deprecated (gone in 5.x) but still feels wrong to break it on
such an old bugfix branch...

Net/net this is a biggish change, and I don't think we should backport
this to 4.10.x: this branch is very old now, and this change is a too risky.


> 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-410x.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, 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

Reply via email to