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

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: [EMAIL PROTECTED]
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

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" <[EMAIL PROTECTED]>:

> 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: [EMAIL PROTECTED]
> 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
>

: 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