[
https://issues.apache.org/jira/browse/SOLR-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398874#comment-13398874
]
Ronny Karallus edited comment on SOLR-2654 at 6/21/12 9:28 PM:
---------------------------------------------------------------
We just occured this problem using the spellchecking component. We got Solr 3.5
running.
Our configuration is:
...
<indexDefaults>
...
<lockType>simple</lockType>
</indexDefaults>
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
<str name="queryAnalyzerFieldType">textSpell</str>
<lst name="spellchecker">
<str name="name">default</str>
<str name="field">_spell</str>
<str name="spellcheckIndexDir">./spellchecker1</str>
<str name="buildOnCommit">true</str>
</lst>
...
</searchComponent>
That results in:
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed
out: NativeFSLock@.../data/spellchecker1/write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:84)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108)
at
org.apache.lucene.search.spell.SpellChecker.setSpellIndex(SpellChecker.java:169)
at
org.apache.lucene.search.spell.SpellChecker.<init>(SpellChecker.java:149)
at
org.apache.solr.spelling.AbstractLuceneSpellChecker.init(AbstractLuceneSpellChecker.java:127)
... 22 more
Our FS doesnt support native locking. That's why we configured locktype to
simple. However, the Spellchecker code doesn't use this setting ... That can be
read pretty easy from the code:
Solr AbstractLuceneSpellChecker:
protected void initIndex() throws IOException {
if (indexDir != null) {
index = FSDirectory.open(new File(indexDir));
} else {
index = new RAMDirectory();
}
}
=> doesnt give a locking factory so the default is used
Lucene FSDirectory:
protected FSDirectory(File path, LockFactory lockFactory) throws IOException {
// new ctors use always NativeFSLockFactory as default:
if (lockFactory == null) {
lockFactory = new NativeFSLockFactory();
}
directory = getCanonicalPath(path);
if (directory.exists() && !directory.isDirectory())
throw new NoSuchDirectoryException("file '" + directory + "' exists but
is not a directory");
setLockFactory(lockFactory);
}
=> the default is NativeFSLock
I think that makes the problem a little less theoretical and more severe then
the read scenario
was (Author: rkarallus):
We just occured this problem using the spellchecking component. We got Solr
3.5 running.
Our configuration is:
...
<indexDefaults>
...
<lockType>simple</lockType>
</indexDefaults>
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
<str name="queryAnalyzerFieldType">textSpell</str>
<lst name="spellchecker">
<str name="name">default</str>
<str name="field">_spell</str>
<str name="spellcheckIndexDir">./spellchecker1</str>
<str name="buildOnCommit">true</str>
</lst>
...
</searchComponent>
That results in:
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed
out: NativeFSLock@.../data/spellchecker1/write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:84)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108)
at
org.apache.lucene.search.spell.SpellChecker.setSpellIndex(SpellChecker.java:169)
at
org.apache.lucene.search.spell.SpellChecker.<init>(SpellChecker.java:149)
at
org.apache.solr.spelling.AbstractLuceneSpellChecker.init(AbstractLuceneSpellChecker.java:127)
... 22 more
Our FS doesnt support native locking. That's why we configured locktype to
simple. However, the Spellchecker code doesn't use this setting ... That can be
read pretty easy from the code:
Solr AbstractLuceneSpellChecker:
protected void initIndex() throws IOException {
if (indexDir != null) {
index = FSDirectory.open(new File(indexDir));
} else {
index = new RAMDirectory();
}
}
=> doesnt give a locking factory so the default is used
Lucene FSDirectory:
protected FSDirectory(File path, LockFactory lockFactory) throws IOException {
// new ctors use always NativeFSLockFactory as default:
if (lockFactory == null) {
lockFactory = new NativeFSLockFactory();
}
directory = getCanonicalPath(path);
if (directory.exists() && !directory.isDirectory())
throw new NoSuchDirectoryException("file '" + directory + "' exists but
is not a directory");
setLockFactory(lockFactory);
}
=> the default is FNativeFSLock
> <lockType/> not used consistently in all places Directory objects are
> instantiated
> ----------------------------------------------------------------------------------
>
> Key: SOLR-2654
> URL: https://issues.apache.org/jira/browse/SOLR-2654
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Mark Miller
> Fix For: 4.0
>
> Attachments: SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch,
> SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch, SOLR-2654.patch,
> SOLR-2654.patch, SOLR-2698.patch
>
>
> nipunb noted on the mailing list then when configuring solr to use an
> alternate <lockType/> (ie: simple) the stats for the SolrIndexSearcher list
> NativeFSLockFactory being used by the Directory.
> The problem seems to be that SolrIndexConfig is not consulted when
> constructing Directory objects used for IndexReader (it's only used by
> SolrIndexWriter)
> I don't _think_ this is a problem in most cases since the IndexReaders should
> all be readOnly in the core solr code) but plugins could attempt to use them
> in other ways. In general it seems like a really bad bug waiting to happen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
