[
https://issues.apache.org/jira/browse/LUCENE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155978#comment-16155978
]
Erick Erickson commented on LUCENE-7959:
----------------------------------------
bq: i still think there is confusion in the issue description at least
feel free to change as you see fit. All I really are about is that more clues
about what's _really_ wrong if we can safely provide them show up in the logs.
bq: If you get lockobtainfailedexc, its a bug in your code always.
agreed. nit: in this case not code, your setup. But the point is still well
taken, you have a problem you've created for yourself and you have to fix it.
This is about providing clues to help them fix it.
bq: So the suppressed exc can be useful then, maybe
Right, not looking for too much hand-holding here, just anything that could
help the user (or me if I'm supporting them) figure out what the underlying
issue is. The errors currently returned are misleading in this case; there is
no lock held at all by a VM or external process. So any safe thing we can do
that has a _chance_ of helping pinpoint the problem is an improvement.
> 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
> Attachments: LUCENE-7959_untested.patch
>
>
> 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]
