[
https://issues.apache.org/jira/browse/SOLR-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702066#comment-14702066
]
Uwe Schindler commented on SOLR-7942:
-------------------------------------
In any case, the error message should be very rare.
BTW, It's impossible to ever need to unlock the directory in the default config
(NIOFSLockFactory), because the JVM / OS kernel cleans up the lock on JVM exit.
SO the message does not need to be so prominent. In the default config, if
directory is locked you have a second Solr instance somewhere running. Poeple
using HDFS may need more instructions how to remove the lock!
SimpleFSLockFactory is something nobody should use at all (maybe only with
NFS), so this is also not a problematic thing.
> fix error logging when index is locked on startup, add deprecation warning if
> unlockOnStartup is configured
> -----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7942
> URL: https://issues.apache.org/jira/browse/SOLR-7942
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Minor
>
> LUCENE-6508 removed support for unlockOnStartup, but the way the changes are
> made are inconsistent with how other config options have been deprecated in
> the past, and cause a confusing error message if an index is locked on
> startup...
> * in 5x, the SolrConfig constructor should log a warning if the
> unlockOnStartup option is specified (regardless of whether it's true or
> false) so users know they need to cleanup their configs and change their
> expectations (even if they never get - or have not yet gotten - a lock
> problem)
> * in SolrCore, the LockObtainFailedException that is thrown if the index is
> locked should _not_ say "{{Solr now longer supports forceful unlocking via
> 'unlockOnStartup'}}"
> ** besides the no/now typo, this wording missleads users into thinking that
> the LockObtainFailedException error is in some way related to that config
> option -- creating an implication that using that option lead them to this
> error. we shouldn't mention that 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]
