Hello, We don't want to use locktype=native (we are using NFS) or locktype=simple (we mount a read-only snapshot of the index on our search servers and with locktype=simple, Solr refuses to start up becaise it sees the lock file.)
However, we don't quite understand the warnings about using locktype=single in the context of normal Solr operation. The ref guide and the wiki ( http://wiki.apache.org/lucene-java/AvailableLockFactories) seem to indicate there is some danger in using locktype=single. The wiki says: locktype=single: "Uses an object instance to represent the lock, so this is usefull when you are certain that all modifications to the a given index are running against a single shared in-process Directory instance. This is currently the default locking for RAMDirectory, but it could also make sense on a FSDirectory provided the other processes use the index in read-only." We are using Solr. We would not configure two different Solr instances to write to the same index. So why would a "normal" Solr set-up possibly end up having more than one process writing to the same index? At the Lucene level there are multiple index writers per thread, but they each write to their own segments, and (I think) all the threads are in the same Solr process), Are we safe using locktype=single? Tom
