[
https://issues.apache.org/jira/browse/SOLR-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702080#comment-14702080
]
Hoss Man commented on SOLR-7942:
--------------------------------
bq. ...In the default config, if directory is locked you have a second Solr
instance somewhere running....
right: i'd like to improve that errmsg to make the most common situation
(multiple instances) more obvious, but also point out it depends on your
config. the main thing though is to stop mentioning unlockOnStartup completley
-- because right now even if you aren't using it, you'll get an error
mentioning it, and if you go searching for it it'll be hard to find because
we're removing it from the ref guide.
the only time you should ever get a log msg mentioning unlockOnStartup is_if_
you already have it configured -- then we should tell you to stop (the first
point)
----
In any case, this isn't a major issue, i just wanted to file it as a reminder
to clean it up as soon as i have some time.
> 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]
