[
https://issues.apache.org/jira/browse/LUCENE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14562733#comment-14562733
]
Robert Muir commented on LUCENE-6507:
-------------------------------------
Also, LockStressTest from our ant task is not exercising the intra-JVM case, it
has never failed on these things.
We should be seeing test failures.
But just staring at code, you can see the bugs/races:
{code}
// obtain()
if (obtained == false) { // not successful - clear up and move out
clearLockHeld(path); // #1
clear global map
final FileChannel toClose = channel;
channel = null;
IOUtils.closeWhileHandlingException(toClose); // #2 close channel
}
...
// close()
try {
if (lock != null) {
try {
lock.release();
lock = null;
} finally {
clearLockHeld(path); // #1 clear global map
}
}
} finally {
IOUtils.close(channel); // #2 close channel
channel = null;
}
{code}
#1 and #2 happen in the wrong order.
We must close the channel first for the current code to even stand a chance of
working.
IMO this should block the release.
> 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]
