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" <j...@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 >
