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 Dirk Högemann <di...@googlemail.com> on 2012/08/21 15:17:28 UTC

Auto commit exception in Solr 4.0 Beta

Hello,

I am trying to make our search application Solr 4.0 (Beta) ready and
elaborate on the tasks necessary to accomplish this.
When I try to reindex our documents I get the following exception:

 auto commit error...:java.lang.UnsupportedOperationException: this codec
can only be used for reading
        at
org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.writeLiveDocs(Lucene3xCodec.java:74)
        at
org.apache.lucene.index.ReadersAndLiveDocs.writeLiveDocs(ReadersAndLiveDocs.java:278)
        at
org.apache.lucene.index.IndexWriter$ReaderPool.release(IndexWriter.java:435)
        at
org.apache.lucene.index.BufferedDeletesStream.applyDeletes(BufferedDeletesStream.java:278)
        at
org.apache.lucene.index.IndexWriter.applyAllDeletes(IndexWriter.java:2928)
        at
org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:2919)
        at
org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2666)
        at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2793)
        at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2773)
        at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:531)
        at org.apache.solr.update.CommitTracker.run(CommitTracker.java:214)
        at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
        at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
        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)

Is this a known bug, or is it maybe a Classpath problem I am facing here?

Best
Dirk Hoegemann

Re: Auto commit exception in Solr 4.0 Beta

Posted by Chris Hostetter <ho...@fucit.org>.
: Perfect. I reindexed the whole index and everything worked fine. The
: exception was just a little bit confusing.

Dirk: I'm glad you were able to work arround this, but it's definitely 
suprising to me thta you got this exception, because it doesn't match my 
understanding of what is supported in re-using an existing index when 
upgrading.

I've started a thread on the dev list to sanity check my understanding, 
and ensure that we either fix this automaticly or provide better docs on 
how to upgrade the index format.


-Hoss

Re: Auto commit exception in Solr 4.0 Beta

Posted by Dirk Högemann <di...@googlemail.com>.
Perfect. I reindexed the whole index and everything worked fine. The
exception was just a little bit confusing.
Best
Dirk
Am 21.08.2012 14:39 schrieb "Jack Krupansky" <ja...@basetechnology.com>:

> Did you explicitly run the IndexUpgrader before adding new documents?
>
> In theory, you don't have to do that, but... who knows for sure.
>
> While you wait for one of the hard-core Lucene guys to respond, you could
> try IndexUpgrader, if you haven't already.
>
> OTOH, if you are in fact reindexing (rather than reusing your old index),
> why not start with an empty 4.0 index?
>
> From CHANGES.TXT:
>
> - On upgrading to 4.0, if you do not fully reindex your documents,
>  Lucene will emulate the new flex API on top of the old index,
>  incurring some performance cost (up to ~10% slowdown, typically).
>  To prevent this slowdown, use oal.index.IndexUpgrader
>  to upgrade your indexes to latest file format (LUCENE-3082).
>
>  Mixed flex/pre-flex indexes are perfectly fine -- the two
>  emulation layers (flex API on pre-flex index, and pre-flex API on
>  flex index) will remap the access as required.  So on upgrading to
>  4.0 you can start indexing new documents into an existing index.
>  To get optimal performance, use oal.index.IndexUpgrader
>  to upgrade your indexes to latest file format (LUCENE-3082).
>
> -- Jack Krupansky
>
> -----Original Message----- From: Dirk Högemann
> Sent: Tuesday, August 21, 2012 9:17 AM
> To: solr-user@lucene.apache.org
> Subject: Auto commit exception in Solr 4.0 Beta
>
> Hello,
>
> I am trying to make our search application Solr 4.0 (Beta) ready and
> elaborate on the tasks necessary to accomplish this.
> When I try to reindex our documents I get the following exception:
>
> auto commit error...:java.lang.**UnsupportedOperationException: this codec
> can only be used for reading
>        at
> org.apache.lucene.codecs.**lucene3x.Lucene3xCodec$1.**
> writeLiveDocs(Lucene3xCodec.**java:74)
>        at
> org.apache.lucene.index.**ReadersAndLiveDocs.**writeLiveDocs(**
> ReadersAndLiveDocs.java:278)
>        at
> org.apache.lucene.index.**IndexWriter$ReaderPool.**
> release(IndexWriter.java:435)
>        at
> org.apache.lucene.index.**BufferedDeletesStream.**applyDeletes(**
> BufferedDeletesStream.java:**278)
>        at
> org.apache.lucene.index.**IndexWriter.applyAllDeletes(**
> IndexWriter.java:2928)
>        at
> org.apache.lucene.index.**IndexWriter.maybeApplyDeletes(**
> IndexWriter.java:2919)
>        at
> org.apache.lucene.index.**IndexWriter.prepareCommit(**
> IndexWriter.java:2666)
>        at
> org.apache.lucene.index.**IndexWriter.commitInternal(**
> IndexWriter.java:2793)
>        at org.apache.lucene.index.**IndexWriter.commit(**
> IndexWriter.java:2773)
>        at
> org.apache.solr.update.**DirectUpdateHandler2.commit(**
> DirectUpdateHandler2.java:531)
>        at org.apache.solr.update.**CommitTracker.run(**
> CommitTracker.java:214)
>        at
> java.util.concurrent.**Executors$RunnableAdapter.**
> call(Executors.java:441)
>        at
> java.util.concurrent.**FutureTask$Sync.innerRun(**FutureTask.java:303)
>        at java.util.concurrent.**FutureTask.run(FutureTask.**java:138)
>        at
> java.util.concurrent.**ScheduledThreadPoolExecutor$**
> ScheduledFutureTask.access$**301(**ScheduledThreadPoolExecutor.**java:98)
>        at
> java.util.concurrent.**ScheduledThreadPoolExecutor$**
> ScheduledFutureTask.run(**ScheduledThreadPoolExecutor.**java:206)
>        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)
>
> Is this a known bug, or is it maybe a Classpath problem I am facing here?
>
> Best
> Dirk Hoegemann
>

Re: Auto commit exception in Solr 4.0 Beta

Posted by Jack Krupansky <ja...@basetechnology.com>.
Did you explicitly run the IndexUpgrader before adding new documents?

In theory, you don't have to do that, but... who knows for sure.

While you wait for one of the hard-core Lucene guys to respond, you could 
try IndexUpgrader, if you haven't already.

OTOH, if you are in fact reindexing (rather than reusing your old index), 
why not start with an empty 4.0 index?

>From CHANGES.TXT:

- On upgrading to 4.0, if you do not fully reindex your documents,
  Lucene will emulate the new flex API on top of the old index,
  incurring some performance cost (up to ~10% slowdown, typically).
  To prevent this slowdown, use oal.index.IndexUpgrader
  to upgrade your indexes to latest file format (LUCENE-3082).

  Mixed flex/pre-flex indexes are perfectly fine -- the two
  emulation layers (flex API on pre-flex index, and pre-flex API on
  flex index) will remap the access as required.  So on upgrading to
  4.0 you can start indexing new documents into an existing index.
  To get optimal performance, use oal.index.IndexUpgrader
  to upgrade your indexes to latest file format (LUCENE-3082).

-- Jack Krupansky

-----Original Message----- 
From: Dirk Högemann
Sent: Tuesday, August 21, 2012 9:17 AM
To: solr-user@lucene.apache.org
Subject: Auto commit exception in Solr 4.0 Beta

Hello,

I am trying to make our search application Solr 4.0 (Beta) ready and
elaborate on the tasks necessary to accomplish this.
When I try to reindex our documents I get the following exception:

auto commit error...:java.lang.UnsupportedOperationException: this codec
can only be used for reading
        at
org.apache.lucene.codecs.lucene3x.Lucene3xCodec$1.writeLiveDocs(Lucene3xCodec.java:74)
        at
org.apache.lucene.index.ReadersAndLiveDocs.writeLiveDocs(ReadersAndLiveDocs.java:278)
        at
org.apache.lucene.index.IndexWriter$ReaderPool.release(IndexWriter.java:435)
        at
org.apache.lucene.index.BufferedDeletesStream.applyDeletes(BufferedDeletesStream.java:278)
        at
org.apache.lucene.index.IndexWriter.applyAllDeletes(IndexWriter.java:2928)
        at
org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:2919)
        at
org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2666)
        at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2793)
        at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2773)
        at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:531)
        at org.apache.solr.update.CommitTracker.run(CommitTracker.java:214)
        at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
        at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
        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)

Is this a known bug, or is it maybe a Classpath problem I am facing here?

Best
Dirk Hoegemann