[
https://issues.apache.org/jira/browse/LUCENE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155652#comment-16155652
]
Shawn Heisey commented on LUCENE-7959:
--------------------------------------
This is what I think should be there, including some comments:
{code}
// If the lockfile already exists, we're going to do nothing.
// If there are problems with that lockfile, they will be caught later.
// If we *do* create the file here, exceptions will propagate upward.
if (Files.notExists(lockFile))
{
Files.createFile(lockFile);
}
{code}
If the file already exists, it won't try to create it, and the later code can
blow up like it already does if the lock fails. If the file doesn't exist,
then creation is attempted. If that creation fails, and Java can create a
reasonable exception explaining WHY it failed, then the calling code will have
that information.
The problem I see with the current code is that when lockfile creation fails,
the *reason* for the failure is completely lost. An exception is thrown later,
but it's an almost useless "NoSuchFileException", which is covered by the
method's signature (that includes IOException). It would be better to have the
file creation call throw an appropriate IOException, or one derived from it.
Then the caller will know that permissions are wrong, or they're out of disk
space, or some other problem.
> Throw more helpful error messages from failures in obtainFSLock, at least in
> NativeFSLockFactory
> ------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7959
> URL: https://issues.apache.org/jira/browse/LUCENE-7959
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
>
> This is one of those small changes that would save a lot of pain for end
> users. Currently, any failure to obtain the lock reports:
> "Lock held by this virtual machine: " + realPath
> or
> "Lock held by another program: " + realPath
> Let's say that there's a permissions issue with the index dir. This is an
> unhelpful/misleading error message (recent user's list discussion about this).
> The problem is that when we try to create the lock file we swallow _all_
> exceptions, not just the one we don't care about (Thanks [~elyograg] for
> pointing this out).
> {{
> try {
> Files.createFile(lockFile);
> } catch (IOException ignore) {
> // we must create the file to have a truly canonical path.
> // if it's already created, we don't care. if it cant be created, it
> will fail below.
> }
> }}
> It fails later with one of the above error messages.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
