OK thanks for the infoStream output -- it was very helpful! It looks like you have a single large segment that has deletions... it could be it's over the max merge size. Can you try setting tmp.setMaxMergedSegmentMB to something very large and see if the expunge then runs?
I think TMP shouldn't enforce this max during expunge, ie, it should always merge if the seg has too many deletions. I'll open an issue... Mike McCandless http://blog.mikemccandless.com On Mon, Sep 12, 2011 at 2:10 PM, <v.se...@lombardodier.com> wrote: > Hi, > > here is the code: > > writer.commit(); // make sure nothing is buffered > mgr.printIndexState("Expunging deletes using " + writer > .getConfig().getMergePolicy()); > setDirectLogger(); // redirect infoStream toward log4j > writer.expungeDeletes(); > writer.commit(); > mgr.printIndexState("Expunging deletes done"); > > public void printIndexState(String context) throws IOException { > IndexReader reader = openReader(); > > try { > log.info(context + ": numDocs=" + reader.numDocs() + "; > numDeletedDocs=" + reader.numDeletedDocs() + "; indexSize=" + > getIndexSizeMb() + "Mb"); > } finally { > reader.close(); > } > } > > public IndexReader openReader() { > try { > return IndexReader.open(writer, false); > } catch (IOException e) { > log.warn("unable to open reader", e); > throw new RuntimeException("unable to open reader", e); > } > } > > here is the log: > > 2011-09-12 20:07:02,009 INFO [com.lodh.arte.logserver.LuceneMgr] > (LogServer optimize) Expunging deletes using [TieredMergePolicy: > maxMergeAtOnce=10, maxMergeAtOnceExplicit=30, maxMergedSegmentMB=5120.0, > floorSegmentMB=2.0, expungeDeletesPctAllowed=0.0, segmentsPerTier=10.0, > useCompoundFile=true, noCFSRatio=0.1: numDocs=25077714; > numDeletedDocs=4340449; indexSize=71324Mb > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IFD [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: setInfoStream > deletionPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy@5367839e > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: > dir=org.apache.lucene.store.MMapDirectory@F:\logserver\index\INFRA-LOGSERVER1_UNIV_UNIV_DBIZ > lockFactory=org.apache.lucene.store.NativeFSLockFactory@30f224d9 > index=_m5eqf(3.3):C19380892/4340449 _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 > _m627z(3.3):c259956 _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 > _m63ah(3.3):c936 _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 > _m63ce(3.3):c708 _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > version=3.3.0 1139782 - 2011-06-26 09:17:59 > matchVersion=LUCENE_31 > analyzer=org.apache.lucene.analysis.PerFieldAnalyzerWrapper > delPolicy=org.apache.lucene.index.KeepOnlyLastCommitDeletionPolicy > commit=null > openMode=CREATE_OR_APPEND > similarity=org.apache.lucene.search.DefaultSimilarity > termIndexInterval=128 > mergeScheduler=org.apache.lucene.index.ConcurrentMergeScheduler > default WRITE_LOCK_TIMEOUT=1000 > writeLockTimeout=1000 > maxBufferedDeleteTerms=-1 > ramBufferSizeMB=16.0 > maxBufferedDocs=-1 > mergedSegmentWarmer=null > mergePolicy=[TieredMergePolicy: maxMergeAtOnce=10, > maxMergeAtOnceExplicit=30, maxMergedSegmentMB=5120.0, floorSegmentMB=2.0, > expungeDeletesPctAllowed=0.0, segmentsPerTier=10.0, useCompoundFile=true, > noCFSRatio=0.1 > maxThreadStates=8 > readerPooling=false > readerTermsIndexDivisor=1 > > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: now trigger flush reason=explicit flush > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: start flush: applyAllDeletes=true > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: index before flush _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: DW: flush: no docs; skipping > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: apply all deletes during flush > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE BD 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: applyDeletes: no deletes; skipping > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE BD 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: prune sis=org.apache.lucene.index.SegmentInfos@2ab94ec7 > minGen=182 packetCount=0 > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: clearFlushPending > 2011-09-12 20:07:02,010 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: expungeDeletes: index now _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: findMergesToExpungeDeletes > infos=_m5eqf(3.3):C19380892/4340449 _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 > _m627z(3.3):c259956 _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 > _m63ah(3.3):c936 _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 > _m63ce(3.3):c708 _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > expungeDeletesPctAllowed=0.0 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: eligible=[_m5eqf(3.3):C19380892/4340449] > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: now merge > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: index: _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: no more merges pending; now return > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: commit: start > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: commit: enter lock > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: commit: now prepare > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: prepareCommit: flush > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: now trigger flush reason=explicit flush > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: start flush: applyAllDeletes=true > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: index before flush _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: DW: flush: no docs; skipping > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: apply all deletes during flush > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE BD 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: applyDeletes: no deletes; skipping > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE BD 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: prune sis=org.apache.lucene.index.SegmentInfos@2ab94ec7 > minGen=182 packetCount=0 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: clearFlushPending > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: startCommit(): start > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: skip startCommit(): no changes pending > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: commit: pendingCommit == null; skip > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: commit: done > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: flush at getReader > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: now trigger flush reason=explicit flush > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: start flush: applyAllDeletes=false > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: index before flush _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,011 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: DW: flush: no docs; skipping > 2011-09-12 20:07:02,012 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: don't apply deletes now delTermCount=0 bytesUsed=0 > 2011-09-12 20:07:02,012 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: clearFlushPending > 2011-09-12 20:07:02,013 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: return reader version=1305975958585 > reader=ReadOnlyDirectoryReader(segments_4d755:nrt > _m5eqf(3.3):C19380892/4340449 _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 > _m627z(3.3):c259956 _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 > _m63ah(3.3):c936 _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 > _m63ce(3.3):c708 _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481) > 2011-09-12 20:07:02,013 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: findMerges: 15 segments > 2011-09-12 20:07:02,013 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m5eqf(3.3):C19380892/4340449 size=39901.436 MB > [skip: too large] > 2011-09-12 20:07:02,013 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m5eqg(3.3):C9760743 size=19338.310 MB [skip: too > large] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m627z(3.3):c259956 size=531.258 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m637u(3.3):c7630 size=17.103 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63c2(3.3):c1174 size=3.026 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63ah(3.3):c936 size=2.663 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63ae(3.3):c932 size=2.659 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63c4(3.3):c1228 size=2.084 MB > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63em(3.3):c886 size=1.771 MB [floored] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63ec(3.3):c570 size=1.682 MB [floored] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63ce(3.3):c708 size=1.671 MB [floored] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63di(3.3):c481 size=1.653 MB [floored] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63e2(3.3):c873 size=1.548 MB [floored] > 2011-09-12 20:07:02,014 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63ds(3.3):c705 size=1.404 MB [floored] > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: seg=_m63aj(3.3):c449 size=1.389 MB [floored] > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: TMP: allowedSegmentCount=22 vs count=15 (eligible count=13) > tooBigCount=2 > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: now merge > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: index: _m5eqf(3.3):C19380892/4340449 > _m5eqg(3.3):C9760743 _m63c4(3.3):c1228 _m627z(3.3):c259956 > _m637u(3.3):c7630 _m63e2(3.3):c873 _m63ae(3.3):c932 _m63ah(3.3):c936 > _m63aj(3.3):c449 _m63ec(3.3):c570 _m63em(3.3):c886 _m63ce(3.3):c708 > _m63ds(3.3):c705 _m63c2(3.3):c1174 _m63di(3.3):c481 > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: CMS: no more merges pending; now return > 2011-09-12 20:07:02,015 INFO [com.lodh.arte.logserver.LuceneWriter] > (LogServer optimize) LUCENE IW 0 [Mon Sep 12 20:07:02 CEST 2011; LogServer > optimize]: getReader took 4 msec > 2011-09-12 20:07:02,016 INFO [com.lodh.arte.logserver.LuceneMgr] > (LogServer optimize) Expunging deletes done: numDocs=25077714; > numDeletedDocs=4340449; indexSize=71324Mb > > regards, > > vincent > > > > > > > > > > > Michael McCandless <luc...@mikemccandless.com> > > > 12.09.2011 18:20 > Please respond to > java-user@lucene.apache.org > > > > To > java-user@lucene.apache.org > cc > > Subject > Re: optimize with num segments > 1 index keeps growing > > > > > > > Hmm... are you using IndexReader.numDeletedDocs to check? > > Did you commit from the writer and then reopen the IndexReader before > calling .numDeletedDocs? Else the reader won't see the change. > > Mike McCandless > > http://blog.mikemccandless.com > > On Sat, Sep 10, 2011 at 11:58 PM, <v.se...@lombardodier.com> wrote: >> Hi, even with setExpungeDeletesPctAllowed(0.0), I could not get docs to >> get removed from disk. >> after the expunge+commit I print again the numDeletedDocs, and it stays >> the same. >> regards, >> vincent >> >> >> >> >> >> >> >> >> >> >> Michael McCandless <luc...@mikemccandless.com> >> >> >> 09.09.2011 20:53 >> Please respond to >> java-user@lucene.apache.org >> >> >> >> To >> java-user@lucene.apache.org >> cc >> >> Subject >> Re: optimize with num segments > 1 index keeps growing >> >> >> >> >> >> >> TieredMergePolicy by default will only merge a segment if it has > 10% >> deletions. >> >> Can you try calling .setExpungeDeletesPctAllowed(0.0) and then expunge >> again? >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> On Fri, Sep 9, 2011 at 1:41 PM, <v.se...@lombardodier.com> wrote: >>> Hi, >>> >>> this post is quite old, but I would like to share some recen >> developments. >>> >>> I applied the recommandation. my process became: expunge deletes and >>> optimize 2 segments. >>> >>> at the time I was with lucene 3.1 and that solved my issue. recently I >>> moved to lucene 3.3, and I tried playing with the new tiered merge >> policy. >>> what I found was that after an expunge, the number of deleted docs > would >>> stay the same, and space would not be reclaimed on the disk. I switched >>> back to the default merge policy (LogByteSizeMergePolicy: >>> minMergeSize=1677721, mergeFactor=10, maxMergeSize=2147483648, >>> maxMergeSizeForOptimize=9223372036854775807, >> calibrateSizeByDeletes=true, >>> maxMergeDocs=2147483647, useCompoundFile=true, noCFSRatio=0.1) and got >>> this time the right behavior : size was reclaimed on disk. I even tried >>> with the BalancedSegmentMergePolicy and got again the right behavior. >>> >>> so this issue seems to affect only the tiered merge policy. >>> >>> to illustrate this, I took an index with many deleted docs then >>> expunged/optimized while using the tiered policy, then did the same >> thing >>> with a default merge policy. here is for each step the content of the >>> directory: >>> >>> before: >>> >>> 09.09.2011 17:38 20 segments.gen >>> 09.09.2011 17:38 5'335 segments_4bf1u >>> 06.09.2011 15:27 0 write.lock >>> 06.09.2011 00:49 31'681'157'794 _jhwld.fdt >>> 06.09.2011 00:49 115'562'268 _jhwld.fdx >>> 06.09.2011 00:37 5'347 _jhwld.fnm >>> 06.09.2011 01:13 7'147'947'472 _jhwld.frq >>> 06.09.2011 01:13 3'927'649'164 _jhwld.prx >>> 06.09.2011 01:13 41'992'760 _jhwld.tii >>> 06.09.2011 01:13 3'745'729'056 _jhwld.tis >>> 09.09.2011 00:27 1'805'669 _jhwld_3.del >>> 09.09.2011 00:31 11'397'619'448 _jtrwg.fdt >>> 09.09.2011 00:31 98'393'316 _jtrwg.fdx >>> 09.09.2011 00:27 5'347 _jtrwg.fnm >>> 09.09.2011 00:47 5'146'273'732 _jtrwg.frq >>> 09.09.2011 00:47 1'661'436'146 _jtrwg.prx >>> 09.09.2011 00:47 23'950'194 _jtrwg.tii >>> 09.09.2011 00:47 2'139'903'139 _jtrwg.tis >>> 09.09.2011 07:39 94'471'867 _jugaa.cfs >>> 09.09.2011 10:14 252'716'611 _juok2.cfs >>> 09.09.2011 15:45 7'986'102 _jwuaq.cfs >>> 09.09.2011 16:00 5'780'703 _jx45g.cfs >>> 09.09.2011 16:00 333'981'384 _jx46a.cfs >>> 09.09.2011 16:23 20'955'761 _jxge0.cfs >>> 09.09.2011 16:46 19'258'025 _jxmas.cfs >>> 09.09.2011 16:55 16'622'800 _jxpv4.cfs >>> 09.09.2011 17:10 14'605'028 _jxvd6.cfs >>> 09.09.2011 17:34 12'456'476 _jy28o.cfs >>> 09.09.2011 17:38 2'584'950 _jy91y.cfs >>> 09.09.2011 17:38 2'595'049 _jy92i.cfs >>> 09.09.2011 17:38 2'600'991 _jy932.cfs >>> 09.09.2011 17:38 2'610'278 _jy93m.cfs >>> 09.09.2011 17:38 46'664 _jy93x.cfs >>> 09.09.2011 17:38 9'765 _jy93y.cfs >>> 09.09.2011 17:38 10'691 _jy93z.cfs >>> 09.09.2011 17:38 9'533 _jy940.cfs >>> 09.09.2011 17:38 11'684 _jy941.cfs >>> 09.09.2011 17:38 8'996 _jy942.cfs >>> 38 File(s) 67'918'759'565 bytes >>> >>> >>> after expunge/optimize (tiered merge policy): >>> >>> 09.09.2011 18:02 20 segments.gen >>> 09.09.2011 18:02 3'171 segments_4bf3g >>> 06.09.2011 15:27 0 write.lock >>> 06.09.2011 00:49 31'681'157'794 _jhwld.fdt >>> 06.09.2011 00:49 115'562'268 _jhwld.fdx >>> 06.09.2011 00:37 5'347 _jhwld.fnm >>> 06.09.2011 01:13 7'147'947'472 _jhwld.frq >>> 06.09.2011 01:13 3'927'649'164 _jhwld.prx >>> 06.09.2011 01:13 41'992'760 _jhwld.tii >>> 06.09.2011 01:13 3'745'729'056 _jhwld.tis >>> 09.09.2011 17:39 1'805'669 _jhwld_4.del >>> 09.09.2011 17:45 11'814'367'373 _jy9iy.fdt >>> 09.09.2011 17:45 101'565'036 _jy9iy.fdx >>> 09.09.2011 17:39 5'347 _jy9iy.fnm >>> 09.09.2011 18:01 5'328'530'169 _jy9iy.frq >>> 09.09.2011 18:01 1'733'490'572 _jy9iy.prx >>> 09.09.2011 18:01 25'072'713 _jy9iy.tii >>> 09.09.2011 18:01 2'239'702'399 _jy9iy.tis >>> 09.09.2011 18:02 185'962 _jy9mv.cfs >>> 09.09.2011 18:02 9'955 _jy9mw.cfs >>> 09.09.2011 18:02 10'380 _jy9mx.cfs >>> 09.09.2011 18:02 9'341 _jy9my.cfs >>> 09.09.2011 18:02 9'228 _jy9mz.cfs >>> 09.09.2011 18:02 10'382 _jy9n0.cfs >>> 09.09.2011 18:02 9'345 _jy9n1.cfs >>> 09.09.2011 18:02 9'231 _jy9n2.cfs >>> 09.09.2011 18:02 8'961 _jy9n3.cfs >>> 09.09.2011 18:02 10'381 _jy9n4.cfs >>> 09.09.2011 18:02 199'651 _jy9n5.cfs >>> 09.09.2011 18:02 9'345 _jy9n6.cfs >>> 09.09.2011 18:02 9'230 _jy9n7.cfs >>> 31 File(s) 67'905'077'722 bytes >>> >>> after expungeDeletes/optimize with default merge policy : >>> >>> 09.09.2011 19:31 20 segments.gen >>> 09.09.2011 19:31 2'081 segments_4bfpe >>> 09.09.2011 18:13 0 write.lock >>> 09.09.2011 18:42 30'133'772'814 _jyb4c.fdt >>> 09.09.2011 18:42 103'164'812 _jyb4c.fdx >>> 09.09.2011 18:27 5'347 _jyb4c.fnm >>> 09.09.2011 19:03 6'474'023'590 _jyb4c.frq >>> 09.09.2011 19:03 3'699'406'141 _jyb4c.prx >>> 09.09.2011 19:03 37'900'657 _jyb4c.tii >>> 09.09.2011 19:03 3'380'266'875 _jyb4c.tis >>> 09.09.2011 19:15 11'820'477'088 _jyb4e.fdt >>> 09.09.2011 19:15 101'659'700 _jyb4e.fdx >>> 09.09.2011 19:03 5'347 _jyb4e.fnm >>> 09.09.2011 19:29 5'333'219'797 _jyb4e.frq >>> 09.09.2011 19:29 1'734'633'179 _jyb4e.prx >>> 09.09.2011 19:29 25'105'023 _jyb4e.tii >>> 09.09.2011 19:29 2'242'558'333 _jyb4e.tis >>> 09.09.2011 19:31 223'600 _jyb5t.cfs >>> 09.09.2011 19:31 9'545 _jyb5u.cfs >>> 09.09.2011 19:31 8'963 _jyb5v.cfs >>> 09.09.2011 19:31 9'250 _jyb5w.cfs >>> 09.09.2011 19:31 9'047 _jyb5x.cfs >>> 09.09.2011 19:31 11'253 _jyb5y.cfs >>> 09.09.2011 19:31 11'239 _jyb5z.cfs >>> 24 File(s) 65'086'483'701 bytes >>> >>> any clue to what is happenning? >>> >>> thanks, >>> >>> >>> Vincent >>> >>> >>> >>> >>> >>> >>> >>> >>> "Uwe Schindler" <u...@thetaphi.de> >>> >>> >>> 21.07.2011 22:46 >>> Please respond to >>> java-user@lucene.apache.org >>> >>> >>> >>> To >>> <java-user@lucene.apache.org> >>> cc >>> >>> Subject >>> RE: optimize with num segments > 1 index keeps growing >>> >>> >>> >>> >>> >>> >>> There is also expungeDeletes()... >>> >>> ----- >>> Uwe Schindler >>> H.-H.-Meier-Allee 63, D-28213 Bremen >>> http://www.thetaphi.de >>> eMail: u...@thetaphi.de >>> >>> >>>> -----Original Message----- >>>> From: v.se...@lombardodier.com [mailto:v.se...@lombardodier.com] >>>> Sent: Thursday, July 21, 2011 8:39 PM >>>> To: java-user@lucene.apache.org >>>> Subject: Re: optimize with num segments > 1 index keeps growing >>>> >>>> Hi, thanks for this explanation. >>>> so what is the best solution: merge the large segment (how can I do >>> that) >>> or >>>> work with many segments (10?) so that I will avoid have this "large >>> segment" >>>> issue? >>>> thanks, >>>> vince >>>> >>>> >>>> Vincent Sevel >>>> Lombard Odier Darier Hentsch & Cie >>>> 11, rue de la Corraterie - 1204 Genève - Suisse T +41 22 709 3376 - F >>> +41 >>> 22 709 >>>> 3782 www.lombardodier.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Simon Willnauer <simon.willna...@googlemail.com> >>>> >>>> >>>> 21.07.2011 20:06 >>>> Please respond to >>>> java-user@lucene.apache.org >>>> >>>> >>>> >>>> To >>>> java-user@lucene.apache.org >>>> cc >>>> >>>> Subject >>>> Re: optimize with num segments > 1 index keeps growing >>>> >>>> >>>> >>>> >>>> >>>> >>>> so the problem here is that you have one really big segment _52aho.* >> and >>>> several smaller ones _7e0wz.*, _7e0xu.*, _7e1x5.* .... >>>> if you optimize to 2 segmetns all the smaller segments are merged into >>> one >>>> but all the large segment remains untouched. This means that all >> deleted >>>> documents in the large segment are not removed / freed while if you >>>> optimized to one segment they are removed. In the single seg. >>>> index there is no *.del file present meaning no deletes. Unless you >>> merge >>>> the large segment all you deleted documents are only marked as delete >>> but >>>> not yet removed. >>>> >>>> simon >>>> >>>> On Thu, Jul 21, 2011 at 5:50 PM, <v.se...@lombardodier.com> wrote: >>>> > hi, >>>> > closing after the 2 segments optimize does not change it. >>>> > also I am running with lucene 3.1.0. >>>> > cheers, >>>> > vince >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Ian Lea <ian....@gmail.com> >>>> > >>>> > >>>> > 21.07.2011 17:30 >>>> > Please respond to >>>> > java-user@lucene.apache.org >>>> > >>>> > >>>> > >>>> > To >>>> > java-user@lucene.apache.org >>>> > cc >>>> > >>>> > Subject >>>> > Re: optimize with num segments > 1 index keeps growing >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > A write.lock file with timestamp of 13:58 is in all the listings. > The >>>> > first thing I'd try is to add some IndexWriter.close() calls. >>>> > >>>> > >>>> > -- >>>> > Ian. >>>> > >>>> > >>>> > >>>> > On Thu, Jul 21, 2011 at 4:05 PM, <v.se...@lombardodier.com> wrote: >>>> >> Hi, >>>> >> >>>> >> here is a concrete example. >>>> >> >>>> >> I am starting with an index that has 19017236 docs, which takes >> 58989 >>>> Mb >>>> >> on disk: >>>> >> >>>> >> 21.07.2011 15:21 20 segments.gen >>>> >> 21.07.2011 15:21 2'974 segments_2acy4 >>>> >> 21.07.2011 13:58 0 write.lock >>>> >> 16.07.2011 02:21 33'445'798'886 _52aho.fdt >>>> >> 16.07.2011 02:21 178'723'932 _52aho.fdx >>>> >> 16.07.2011 01:58 5'002 _52aho.fnm >>>> >> 16.07.2011 03:10 9'857'410'889 _52aho.frq >>>> >> 16.07.2011 03:10 4'538'234'846 _52aho.prx >>>> >> 16.07.2011 03:10 61'581'767 _52aho.tii >>>> >> 16.07.2011 03:10 5'505'039'790 _52aho.tis >>>> >> 21.07.2011 01:01 1'899'536 _52aho_5.del >>>> >> 21.07.2011 01:05 4'222'206'034 _6t61z.fdt >>>> >> 21.07.2011 01:05 21'424'556 _6t61z.fdx >>>> >> 21.07.2011 01:01 5'002 _6t61z.fnm >>>> >> 21.07.2011 01:12 1'170'370'187 _6t61z.frq >>>> >> 21.07.2011 01:12 598'373'388 _6t61z.prx >>>> >> 21.07.2011 01:12 7'574'912 _6t61z.tii >>>> >> 21.07.2011 01:12 678'766'206 _6t61z.tis >>>> >> 21.07.2011 13:46 1'458'592'058 _7d6me.cfs >>>> >> 21.07.2011 13:48 15'702'654 _7dhgz.cfs >>>> >> 21.07.2011 13:52 16'800'942 _7dphm.cfs >>>> >> 21.07.2011 13:55 16'714'431 _7dxht.cfs >>>> >> 21.07.2011 14:24 17'505'435 _7e0wz.cfs >>>> >> 21.07.2011 14:24 5'875'852 _7e0xu.cfs >>>> >> 21.07.2011 14:48 18'340'470 _7e1x5.cfs >>>> >> 21.07.2011 15:19 16'978'564 _7e3ck.cfs >>>> >> 21.07.2011 15:21 1'208'656 _7e3hv.cfs >>>> >> 21.07.2011 15:21 19'361 _7e3hw.cfs >>>> >> 28 File(s) 61'855'156'350 bytes >>>> >> >>>> >> I am doing a delete of some of the older documents. after the >> delete, >>>> >> I commit then I optimize down to 2 segments. at the end of the >>>> >> optimize >>>> > the >>>> >> index contains 18702510 docs (314727 were deleted) and it takes now >>>> > 58975 >>>> >> Mb on disk: >>>> >> >>>> >> 21.07.2011 15:37 20 segments.gen >>>> >> 21.07.2011 15:37 524 segments_2acy6 >>>> >> 21.07.2011 13:58 0 write.lock >>>> >> 16.07.2011 02:21 33'445'798'886 _52aho.fdt >>>> >> 16.07.2011 02:21 178'723'932 _52aho.fdx >>>> >> 16.07.2011 01:58 5'002 _52aho.fnm >>>> >> 16.07.2011 03:10 9'857'410'889 _52aho.frq >>>> >> 16.07.2011 03:10 4'538'234'846 _52aho.prx >>>> >> 16.07.2011 03:10 61'581'767 _52aho.tii >>>> >> 16.07.2011 03:10 5'505'039'790 _52aho.tis >>>> >> 21.07.2011 15:23 1'999'945 _52aho_6.del >>>> >> 21.07.2011 15:31 5'194'848'138 _7e3hy.fdt >>>> >> 21.07.2011 15:31 28'613'668 _7e3hy.fdx >>>> >> 21.07.2011 15:25 5'002 _7e3hy.fnm >>>> >> 21.07.2011 15:37 1'529'771'296 _7e3hy.frq >>>> >> 21.07.2011 15:37 726'582'244 _7e3hy.prx >>>> >> 21.07.2011 15:37 8'518'198 _7e3hy.tii >>>> >> 21.07.2011 15:37 763'213'144 _7e3hy.tis >>>> >> 18 File(s) 61'840'347'291 bytes >>>> >> >>>> >> as you can see, size on disk did not really change. at this point I >>>> >> optimize down to 1 segment and at the end the index takes 48273 Mb >> on >>>> >> disk: >>>> >> >>>> >> 21.07.2011 16:46 20 segments.gen >>>> >> 21.07.2011 16:46 278 segments_2acy8 >>>> >> 21.07.2011 13:58 0 write.lock >>>> >> 21.07.2011 16:06 32'901'423'750 _7e3hz.fdt >>>> >> 21.07.2011 16:06 149'582'052 _7e3hz.fdx >>>> >> 21.07.2011 15:42 5'002 _7e3hz.fnm >>>> >> 21.07.2011 16:46 8'608'541'177 _7e3hz.frq >>>> >> 21.07.2011 16:46 4'392'616'115 _7e3hz.prx >>>> >> 21.07.2011 16:46 50'571'856 _7e3hz.tii >>>> >> 21.07.2011 16:46 4'515'914'658 _7e3hz.tis >>>> >> 10 File(s) 50'618'654'908 bytes >>>> >> >>>> >> >>>> >> this means that with the 1 segment optimize I was able to reclaim > 10 >>>> >> Gb >>>> > on >>>> >> disk that the 2 segments optimize could not achieve. >>>> >> >>>> >> how can this be explained? is that a normal behavior? >>>> >> >>>> >> thanks, >>>> >> >>>> >> vince >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Simon Willnauer <simon.willna...@googlemail.com> >>>> >> >>>> >> >>>> >> 20.07.2011 23:11 >>>> >> Please respond to >>>> >> java-user@lucene.apache.org >>>> >> >>>> >> >>>> >> >>>> >> To >>>> >> java-user@lucene.apache.org >>>> >> cc >>>> >> >>>> >> Subject >>>> >> Re: optimize with num segments > 1 index keeps growing >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Jul 20, 2011 at 2:00 PM, <v.se...@lombardodier.com> wrote: >>>> >>> Hi, >>>> >>> >>>> >>> I index several millions small documents per day. each day, I >> remove >>>> >> some >>>> >>> of the older documents to keep the index at a stable number of >>>> >> documents. >>>> >>> after each purge, I commit then I optimize the index. what I found >>>> >>> is >>>> >> that >>>> >>> if I keep optimizing with max num segments = 2, then the index >> keeps >>>> >>> growing on the disk. but as soon as I optimize with just 1 > segment, >>>> the >>>> >>> space gets reclaimed on the disk. so, I have currently adopted the >>>> >>> following strategy : every night I optimize with 2 segments, > except >>>> > once >>>> >>> per week where I optimize with just 1 segment. >>>> >> >>>> >> what do you mean by keeps growing. you have n segments and you >>>> >> optimize down to 2 and the index is bigger than the one with n >>>> >> segments? >>>> >> >>>> >> simon >>>> >>> >>>> >>> is that an expected behavior? >>>> >>> I guess I am doing something special because I was not able to >>>> > reproduce >>>> >>> this behavior in a unit test. what could it be? >>>> >>> >>>> >>> it would be nice to get some explanatory services within the >> product >>>> to >>>> >>> help get some understanding on its behavior. something that tells >>>> >>> you >>>> >> some >>>> >>> information about your index for instance (number of docs in the >>>> >> different >>>> >>> states, how the space is being used, ...). lucene is a wonderful >>>> >> product, >>>> >>> but to me this is almost like black magic, and when there is a >>>> specific >>>> >>> behavior, I have got little clues to figure out something by >> myself. >>>> >> some >>>> >>> user oriented logging would be nice as well (the index writer info >>>> >> stream >>>> >>> is really verbose and very low level). >>>> >>> >>>> >>> thanks for your help, >>>> >>> >>>> >>> >>>> >>> Vince >>>> > >>>> > > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >>>> > For additional commands, e-mail: java-user-h...@lucene.apache.org >>>> > >>>> > >>>> > >>>> > >>>> > ************************ DISCLAIMER >>>> ************************ This >>>> > message is intended only for use by the person to whom it is >>>> > addressed. It may contain information that is privileged and >>>> > confidential. Its content does not constitute a formal commitment by >>>> > Lombard Odier Darier Hentsch & Cie or any of its branches or >>>> > affiliates. >>>> > If you are not the intended recipient of this message, kindly notify >>>> > the sender immediately and destroy this message. Thank You. >>>> > >>>> ********************************************************** >>>> ******* >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: java-user-h...@lucene.apache.org >>>> >>>> >>>> >>>> >>>> ************************ DISCLAIMER ************************ >>>> This message is intended only for use by the person to whom it is >>> addressed. >>>> It may contain information that is privileged and confidential. Its >>> content >>>> does not constitute a formal commitment by Lombard Odier Darier > Hentsch >>>> & Cie or any of its branches or affiliates. >>>> If you are not the intended recipient of this message, kindly notify >> the >>>> sender immediately and destroy this message. Thank You. >>>> ********************************************************** >>>> ******* >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-user-h...@lucene.apache.org >>> >>> >>> >>> >>> ************************ DISCLAIMER ************************ >>> This message is intended only for use by the person to >>> whom it is addressed. It may contain information that is >>> privileged and confidential. Its content does not >>> constitute a formal commitment by Lombard Odier >>> Darier Hentsch & Cie or any of its branches or affiliates. >>> If you are not the intended recipient of this message, >>> kindly notify the sender immediately and destroy this >>> message. Thank You. >>> ***************************************************************** >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org >> >> >> >> >> ************************ DISCLAIMER ************************ >> This message is intended only for use by the person to >> whom it is addressed. It may contain information that is >> privileged and confidential. Its content does not >> constitute a formal commitment by Lombard Odier >> Darier Hentsch & Cie or any of its branches or affiliates. >> If you are not the intended recipient of this message, >> kindly notify the sender immediately and destroy this >> message. Thank You. >> ***************************************************************** >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > ************************ DISCLAIMER ************************ > This message is intended only for use by the person to > whom it is addressed. It may contain information that is > privileged and confidential. Its content does not > constitute a formal commitment by Lombard Odier > Darier Hentsch & Cie or any of its branches or affiliates. > If you are not the intended recipient of this message, > kindly notify the sender immediately and destroy this > message. Thank You. > ***************************************************************** > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
