[
https://issues.apache.org/jira/browse/LUCENE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16156080#comment-16156080
]
Robert Muir commented on LUCENE-7959:
-------------------------------------
{quote}
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.
{quote}
I updated the description, but i also must correct this "nit":
If you get {{org.apache.lucene.store.LockObtainFailedException: Lock held by
this virtual machine}}, you need to stop reading this JIRA issue and go fix
that bug in solr! That happens because you try to open two indexwriters in the
same JVM over the same index, and for no other reason. Its not related to this
JIRA or changed by this patch in any way.
On the other hand, if you get
{{org.apache.lucene.store.LockObtainFailedException: Lock held by another
program}}, then it happens because *two different operating system processes*
each try to open an indexwriter over the same index, and no other reason. In
that case, you may want to ask the user how many solr processes are running on
the machine, etc. Maybe they managed to screw up and start it twice somehow.
The two error messages are intentionally different for this reason, so that its
easier to tell when there is a software bug that needs to be fixed, versus an
operational screw-up or what have you.
> 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.
> Let's say that there's a permissions issue with the index dir. The user will
> get "NoSuchFileException: write.lock" but not understand why the lock file is
> missing (its because it could not be created). 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 NoSuchFileException, which does not provide enough
> information.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
