Hmmm, looking at your stack trace in a bit more detail, this is really suspicious:
Caused by: org.apache.lucene.index.IndexFormatTooNewException: Format version is not supported in file 'segments_1': -12 (needs to be between -9 and -11) This *looks* like your Solr version on your slave is older than the version on your master. Is this possible at all? Best Erick On Fri, Mar 23, 2012 at 11:03 AM, Hakan İlter <hakanil...@gmail.com> wrote: > Hi Erick, > > I've already tried step 2 and 3 but it didn't help. It's almost impossible > to do step 1 for us because of project dead-line. > > Do you have any other suggestion? > > Thank your reply. > > On Fri, Mar 23, 2012 at 4:56 PM, Erick Erickson > <erickerick...@gmail.com>wrote: > >> Hmmm, that is odd. But a trunk build from that long ago is going >> to be almost impossible to debug/fix. The problem with working >> from trunk is that this kind of problem won't get much attention. >> >> I have three suggestions: >> 1> update to current trunk. NOTE: you'll have to completely >> reindex your data, the format of the index has changed >> multiple times since then and there's no back-compatibility >> maintained with non-released major versions. >> 2> delete your entire index on the _master_ and re-index from scratch. >> If you do this, I'd also delete the entire <solr home>/data directory >> on the slaves before replication as well. >> 3> Delete your entire index on the _slave_ and see if you get a >> clean replication. >> >> <3> is the least painful, <1> the most so I'd go in reverse order >> for the above. >> >> Best >> Erick >> >> >> On Wed, Mar 21, 2012 at 8:49 AM, Hakan İlter <hakanil...@gmail.com> wrote: >> > Hi everyone, >> > >> > We are using very early version of Solr 4.0 and we've some replication >> > problems. Actually we used this build more than one year without any >> > problem but when I made some changes on schema.xml, the following problem >> > started. >> > >> > I've just changed schema.xml with adding multiValued="true" attribute to >> > two dynamic fields. >> > >> > Before: >> > .... >> > <dynamicField name="*_spec" type="string" indexed="true" stored="false" >> /> >> > <dynamicField name="*_seo" type="string" indexed="true" stored="false" /> >> > .... >> > >> > After: >> > .... >> > <dynamicField name="*_spec" type="string" indexed="true" stored="false" * >> > multiValued="true"* /> >> > <dynamicField name="*_seo" type="string" indexed="true" stored="false" * >> > multiValued="true"* /> >> > .... >> > >> > After starting tomcats with new configuration, there are no problems >> > occurred. But after a while, I'm seeing this error: >> > >> > *Mar 20, 2012 2:00:05 PM org.apache.solr.handler.ReplicationHandler >> doFetch >> > SEVERE: SnapPull failed >> > org.apache.solr.common.SolrException: Index fetch failed : >> > at >> > org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:340) >> > at >> > >> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:265) >> > at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:166) >> > at >> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >> > at >> > >> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) >> > at >> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) >> > at >> > >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) >> > at >> > >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> > at >> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> > at java.lang.Thread.run(Thread.java:662) >> > Caused by: org.apache.lucene.index.IndexFormatTooNewException: Format >> > version is not supported in file 'segments_1': -12 (needs to be between >> -9 >> > and -11) >> > at >> > >> org.apache.lucene.index.codecs.DefaultSegmentInfosReader.read(DefaultSegmentInfosReader.java:51) >> > at >> org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:230) >> > at >> > >> org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:169) >> > at >> org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:770) >> > at >> > org.apache.solr.update.SolrIndexWriter.<init>(SolrIndexWriter.java:83) >> > at >> > >> org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:102) >> > at >> > >> org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:111) >> > at >> > >> org.apache.solr.update.DirectUpdateHandler2.forceOpenWriter(DirectUpdateHandler2.java:297) >> > at >> org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:484) >> > at >> > org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:330) >> > ... 11 more >> > Mar 20, 2012 2:00:16 PM org.apache.solr.update.SolrIndexWriter finalize >> > SEVERE: SolrIndexWriter was not closed prior to finalize(), indicates a >> bug >> > -- POSSIBLE RESOURCE LEAK!!!* >> > >> > After above error, it works for a while and then tomcats are going down >> > because of out of memory problems. >> > >> > Could this be a bug? What do you suggest? Please don't suggest me to >> update >> > Solr to current version in trunk because we did a lot of changes related >> > with our build of Solr. Updating to current Solr would take at least a >> > couple of weeks. But we need an immediate solution. >> > >> > We are using DIH, our schema version is 1.3, both master and slaves using >> > same binaries, libraries etc. Here are some details about our solr build: >> > >> > Solr Specification Version: 4.0.0.2011.03.28.06.20.50 >> > Solr Implementation Version: 4.0-SNAPSHOT 1086110 - Administrator - >> > 2011-03-28 06:20:50 >> > Lucene Specification Version: 4.0-SNAPSHOT >> > Lucene Implementation Version: 4.0-SNAPSHOT 1086110 - 2011-03-28 06:22:18 >> > >> > Thanks for any help. >>
