You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Hakan İlter <ha...@gmail.com> on 2012/03/21 13:49:15 UTC
Solr 4.0 replication problem
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.
Re: Solr 4.0 replication problem
Posted by Erick Erickson <er...@gmail.com>.
In that case, I'm kind of stuck. You've already rebuilt your index
from scratch and removed it from your slaves. That should have
cleared out most everything that could be an issue. I'd suggest
you set up a pair of machines from scratch and try to set up an
index/replication with your current schema. If a fresh install shows
the same problem, you've probably found a bona-fide bug. But
you'll probably have to fix it yourself if you can't upgrade.
But I really doubt it's a bug, this just smells way too much like
you have something going on you aren't aware of ("interesting"
CLASSPATH issues? Multiple installations of Solr? Someone,
sometime, indexed things to the master you didn't know about
with a newer version?whataver?)
Sorry I can't be more help
Erick
On Fri, Mar 23, 2012 at 12:01 PM, Hakan İlter <ha...@gmail.com> wrote:
> Hi Erick,
>
> It's not possible because both master and slaves using same binaries.
>
> Thanks...
>
>
> On Fri, Mar 23, 2012 at 5:30 PM, Erick Erickson <er...@gmail.com>wrote:
>
>> 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 <ha...@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 <erickerickson@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 <ha...@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.
>> >>
>>
Re: Solr 4.0 replication problem
Posted by Hakan İlter <ha...@gmail.com>.
Hi Erick,
It's not possible because both master and slaves using same binaries.
Thanks...
On Fri, Mar 23, 2012 at 5:30 PM, Erick Erickson <er...@gmail.com>wrote:
> 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 <ha...@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 <erickerickson@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 <ha...@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.
> >>
>
Re: Solr 4.0 replication problem
Posted by Erick Erickson <er...@gmail.com>.
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 <ha...@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 <er...@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 <ha...@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.
>>
Re: Solr 4.0 replication problem
Posted by Hakan İlter <ha...@gmail.com>.
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 <er...@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 <ha...@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.
>
Re: Solr 4.0 replication problem
Posted by Erick Erickson <er...@gmail.com>.
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 <ha...@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.