hi Mike and Yonik ,
There is no other exceptions other than missing segments_cje. the disk still
have 160G more spaces when the disk crash.
current these is only one solr core that accessing this index directory. so
it can't be the file lock problem.
I am not sure is considered as unusual configuration, so i attached the
settings that i changed from the original solrconfig.xml.
<indexDefaults>
<ramBufferSizeMB>256</ramBufferSizeMB>
<maxMergeDocs>2147483647</maxMergeDocs>
<maxFieldLength>10000</maxFieldLength>
<writeLockTimeout>1000</writeLockTimeout>
<commitLockTimeout>10000</commitLockTimeout>
</indexDefaults>
<mainIndex>
<useCompoundFile>false</useCompoundFile>
<ramBufferSizeMB>128</ramBufferSizeMB>
<mergeFactor>15</mergeFactor><!-- default value : 10. Less value speed
up searching, but slow down indexing/ -->
<!-- Deprecated -->
<!--<maxBufferedDocs>1000</maxBufferedDocs>-->
<maxMergeDocs>2147483647</maxMergeDocs>
<maxFieldLength>10000</maxFieldLength>
<!-- If true, unlock any held write or commit locks on startup.
This defeats the locking mechanism that allows multiple
processes to safely access a lucene index, and should be
used with care.
This is not needed if lock type is 'none' or 'single'
-->
<unlockOnStartup>false</unlockOnStartup>
</mainIndex>
<updateHandler class="solr.DirectUpdateHandler2">
<autoCommit>
<maxDocs>1000</maxDocs>
</autoCommit>
</updateHandler>
Thanks a lot for your advice.
On Fri, May 29, 2009 at 5:44 AM, Yonik Seeley <yo...@lucidimagination.com>wrote:
> On Wed, May 27, 2009 at 5:49 AM, Michael McCandless
> <luc...@mikemccandless.com> wrote:
> > Hmm... so in fact it looks like Solr had done a number of commits
> > already (especially, given how large your generation is -- the "cje"
> > in segments_cje means there were a number of commits).
> >
> > Were there any other exceptions leading up to this? Disk full?
> > Anything unusual in your Solr configuration?
> >
> > Is there any chance that a 2nd Solr core attempted to access this same
> > directory?
>
> Solr uses SingleInstanceLockFactory by default... so Solr cores (in a
> multi-core env) would be protected.
> But maybe we should switch to NativeFSLockFactory to be safe from
> other processes (with the downside that it will fail for some
> filesystems).
>
> <!--
> This option specifies which Lucene LockFactory implementation to use.
>
> single = SingleInstanceLockFactory - suggested for a read-only index
> or when there is no possibility of another process trying
> to modify the index.
> native = NativeFSLockFactory
> simple = SimpleFSLockFactory
>
> (For backwards compatibility with Solr 1.2, 'simple' is the default
> if not specified.)
> -->
> <lockType>single</lockType>
>
>
> -Yonik
> http://www.lucidimagination.com
>
