fix error logging when index is locked on startup, add deprecation warning if unlockOnStartup is configured

Details

Description

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.

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.

Uwe Schindler
added a comment - 18/Aug/15 22:07 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.

...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.

Hoss Man
added a comment - 18/Aug/15 22:14 ...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.

Hoss Man
added a comment - 26/Aug/15 22:11 Here's what i had in mind, with the true // 'fail' in trunk changed to false // warn in 5x when backporting.
Anyone have concerns/feedack about the various warning/err msgs?