Thanks... Yes, and no. The main thing is, after the replicate failed below, I checked the master and the files that it complains about below (and several others) did exist... which is where I'm stumped about what is causing the issue (I have added the maxCommits setting you mention below already).
I'll retest to confirm that there is only a single commit happening in this scenario, and it's not some weird oddity to do with Windows just being an arrse with file and path capitalization. -----Original Message----- From: Markus Jelsma [mailto:markus.jel...@openindex.io] Sent: 25 October 2011 20:51 To: solr-user@lucene.apache.org Cc: Jaeger, Jay - DOT Subject: Re: Replication issues with multiple Slaves Are you frequently adding and deleting documents and committing those mutations? Then it might try to download a file that doesnt exist anymore. If that is the case try increasing : <str name="maxCommitsToKeep"></str> > I noted that in these messages the left hand side is lower case > collection, but the right hand side is upper case Collection. > Assuming you did a cut/paste, could you have a core name mismatch > between a master and a slave somehow? > > Otherwise (shudder): could you be doing a commit while the > replication is in progress, causing files to shift about on it? I'd > have expected (perhaps naively) solr to have some sort of lock to > prevent such a problem. But if there is no internal lock, that would > be a serious matter (and could happen to us, too, down the road). > > JRJ > > -----Original Message----- > From: Rob Nicholls [mailto:robst...@hotmail.com] > Sent: Tuesday, October 25, 2011 10:32 AM > To: solr-user@lucene.apache.org > Subject: Replication issues with multiple Slaves > > > Hey guys, > > We have a Master (1 server) and 2 Slaves (2 servers) setup and running > replication across multiple cores. > > However, the replication appears to behave sporadically and often > fails when left to replicate automatically via poll. More often than > not a replicate will fail after the slave has finished pulling down > the segment files, because it cannot find a particular file, giving errors such as: > > Oct 25, 2011 10:00:17 AM org.apache.solr.handler.SnapPuller copyAFile > SEVERE: Unable to move index file from: > D:\web\solr\collection\data\index.20111025100000\_3u.tii to: > D:\web\solr\Collection\data\index\_3u.tiiTrying to do a copy > > SEVERE: Unable to copy index file from: > D:\web\solr\collection\data\index.20111025100000\_3s.fdt to: > D:\web\solr\Collection\data\index\_3s.fdt java.io.FileNotFoundException: > D:\web\solr\collection\data\index.20111025100000\_3s.fdt (The system > cannot find the file specified) at java.io.FileInputStream.open(Native > Method) > at java.io.FileInputStream.<init>(Unknown Source) > at org.apache.solr.common.util.FileUtils.copyFile(FileUtils.java:47) > at org.apache.solr.handler.SnapPuller.copyAFile(SnapPuller.java:585) > at > org.apache.solr.handler.SnapPuller.copyIndexFiles(SnapPuller.java:621) > at > org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:31 > 7) > at > org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler. > java > :267) at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown > Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a > cces > s$101(Unknown Source) at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r > unPe > riodic(Unknown Source) at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r > un(U > nknown Source) at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > > For these files, I checked the master, and they did indeed exist. > > Both slave machines are configured the same, with the same replication > settings and a 60 minutes poll interval. > > Is it perhaps because both slave machines are trying to pull down > files at the same time? (and the other has a lock on the file, thus it > gets skipped > maybe?) > > Note: If I manually force replication on each slave, one at a time, > the replication always seems to work fine. > > > > Is there any obvious explanation or oddities I should be aware of that > may cause this? > > Thanks, > Rob
