[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-6507:
--------------------------------
Attachment: LUCENE-6507.patch
Updated patch. Fixes a test bug in AssertingLock, it can't assert on close
either, for the NoLockFactory case.
e.g. TestIndexWriter.testNoSegmentFile use this intentionally to create more
than one IW on the same dir... this should be cleaned up later, I don't
understand why tests need to do that.
> 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
>
>
> 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
