is it a one off case? do you observerve this frequently? On Thu, Jan 21, 2010 at 11:26 AM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > It's hard to tell without poking around, but one of the first things I'd do > would be to look for /home/solr/cores/core8/index.20100119103919/_6qv.fnm - > does this file/dir really exist? Or, rather, did it exist when the error > happened. > > I'm not looking at the source code now, but is that really the only error you > got? No exception stack trace? > > Otis > -- > Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch > > > > ----- Original Message ---- >> From: Trey <solrt...@gmail.com> >> To: solr-user@lucene.apache.org >> Sent: Wed, January 20, 2010 11:54:43 PM >> Subject: Replication Handler Severe Error: Unable to move index file >> >> Does anyone know what would cause the following error?: >> >> 10:45:10 AM org.apache.solr.handler.SnapPuller copyAFile >> >> SEVERE: *Unable to move index file* from: >> /home/solr/cores/core8/index.20100119103919/_6qv.fnm to: >> /home/solr/cores/core8/index/_6qv.fnm >> This occurred a few days back and we noticed that several full copies of the >> index were subsequently pulled from the master to the slave, effectively >> evicting our live index from RAM (the linux os cache), and killing our query >> performance due to disk io contention. >> >> Has anyone experienced this behavior recently? I found an old thread about >> this error from early 2009, but it looks like it was patched almost a year >> ago: >> http://old.nabble.com/%22Unable-to-move-index-file%22-error-during-replication-td21157722.html >> >> >> Additional Relevant information: >> -We are using the Solr 1.4 official release + a field collapsing patch from >> mid December (which I believe should only affect query side, not indexing / >> replication). >> -Our Replication PollInterval for slaves checking the master is very small >> (15 seconds) >> -We have a multi-box distributed search with each box possessing multiple >> cores >> -We issue a manual (rolling) optimize across the cores on the master once a >> day (occurred ~ 1-2 hours before the above timeline) >> -maxWarmingSearchers is set to 1. > >
-- ----------------------------------------------------- Noble Paul | Systems Architect| AOL | http://aol.com
