You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by superruiye <su...@gmail.com> on 2012/02/01 04:41:50 UTC
Re: Why read past EOF
Does it means I only to ensure reopen readers before deleted.I use default
IndexDeletionPolicy: KeepOnlyLastCommitDeletionPolicy.And another two
IndexDeletionPolicy,SnapshotDeletionPolicy and
PersistentSnapshotDeletionPolicy,I am watching now.Are they useful to this
problem?
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3705542.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
Thanks,you suggest me to creat a my IndexDeletionPolicy,I check
KeepOnlyLastCommitDeletionPolicy.onCommit,it invoke CommitPoint.delete(),but
it only :
deleted = true;
commitsToDelete.add(this);
,and the delete index file operation in other place.
Is it useful that I postpone invoke CommitPoint.delete() (eg.10 minutes) and
reopen indexsearcher every minutes?
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3711995.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Hmm, though, one question: if you are using a single IndexWriter,
always on the same machine, then it should not matter that the
computer's clock is way off.
Because, the DeletionPolicy is comparing timestamps pulled only from a
single clock. Ie the shift won't matter; only relative comparisons
matter.
Or are you somehow comparing timestamps pulled from different clocks
(computers)...?
Mike McCandless
http://blog.mikemccandless.com
On Thu, Feb 16, 2012 at 10:08 PM, superruiye <su...@gmail.com> wrote:
> Oh,I made a mistake.Our testing server's time is faster hours than it should
> be.I reminded workmate to modify it,and index maintain in a range size.
> Thank you all the same.
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3752592.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
OK, thanks for bringing closure!
Mike McCandless
http://blog.mikemccandless.com
On Thu, Feb 16, 2012 at 10:08 PM, superruiye <su...@gmail.com> wrote:
> Oh,I made a mistake.Our testing server's time is faster hours than it should
> be.I reminded workmate to modify it,and index maintain in a range size.
> Thank you all the same.
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3752592.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
Oh,I made a mistake.Our testing server's time is faster hours than it should
be.I reminded workmate to modify it,and index maintain in a range size.
Thank you all the same.
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3752592.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Wait: I see your DP above calling .delete() -- can you verify that
code is in fact invoked? EG print on each onCommit how many commits
are deleted and how many are not?
Mike McCandless
http://blog.mikemccandless.com
On Wed, Feb 15, 2012 at 9:21 PM, superruiye <su...@gmail.com> wrote:
> My IndexWriter only create once and cached in memery.
> I restart tomcat this morning,and the index become 94M...But I restart
> yesterday serveral times ,it still too big...
>
> My deletion policy is in above reply,it only compare the timestamp,not
> actually deleting commits.
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3749057.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
My IndexWriter only create once and cached in memery.
I restart tomcat this morning,and the index become 94M...But I restart
yesterday serveral times ,it still too big...
My deletion policy is in above reply,it only compare the timestamp,not
actually deleting commits.
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3749057.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Is your deletion policy actually deleting commits?
Mike McCandless
http://blog.mikemccandless.com
On Wed, Feb 15, 2012 at 5:21 AM, superruiye <su...@gmail.com> wrote:
> http://lucene.472066.n3.nabble.com/file/n3746464/index.jpg
>
> The index files are same size,and the index increase to 7.5G in one day,but
> it should only 90-100M...
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3746464.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
http://lucene.472066.n3.nabble.com/file/n3746464/index.jpg
The index files are same size,and the index increase to 7.5G in one day,but
it should only 90-100M...
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3746464.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
I'm glad the timed deletion policy is working on NFS!
Thanks for bringing closure,
Mike McCandless
http://blog.mikemccandless.com
On Fri, Feb 10, 2012 at 9:58 PM, superruiye <su...@gmail.com> wrote:
> Thanks for your advice and patient.
> I modify "present",and use stress testing two day(loop search and index),the
> "read past EOF" didn't appeared yet.
> My system structure should be improved, I hope to get your proposal again in
> the future.
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3734296.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
Thanks for your advice and patient.
I modify "present",and use stress testing two day(loop search and index),the
"read past EOF" didn't appeared yet.
My system structure should be improved, I hope to get your proposal again in
the future.
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3734296.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Hmm, there's a problem with the logic here (sorry: this is my fault --
my prior suggestion is flat out wrong!).
The problem is... say you commit once, creating commit point 1. Two
hours later, you commit again, creating commit point 2. The bug is,
at this point, immediately on committing commit point 2, this deletion
policy will go and remove commit point 1. Instead, it's supposed to
wait 10 minutes to do so.
So... I think you should go back to using System.currentTimeMillis()
as "the present". And then, only when the newest commit is more than
10 minutes old, are you allowed to delete the commits before it. That
should work?
However: you should leave a margin of error, because say the reader
takes 10 seconds to reopen + warm/cutover all search threads... then,
if timing is unlucky, you can still remove a commit point being used
by a reader. I would leave a comfortable margin, eg if you reopen
readers every 10 minutes, then delete commits older than 15 or 20
minutes. If commits are rare than leaving a fat margin here will cost
nothing in practice... and if there is some clock change
(System.currentTimeMillis() suddenly jumps, maybe from daylight
savings time, maybe from aggressive clock syncing, whatever), you have
some margin....
Really, a better overall design would be a hard handshake will all
outstanding readers, so that only once every single reader using a
given commit has closed, do you delete the commit. Then you are
immune clock unreliability.... but this'd require remote communication
in your app to track reader states.
Also, you should remove that dangerous auto-generated-catch-block? It
may suppress a real exception some day... and onCommit is allowed to
throw IOE.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Feb 7, 2012 at 9:15 PM, superruiye <su...@gmail.com> wrote:
> public class PostponeCommitDeletionPolicy implements IndexDeletionPolicy {
> private final static long deletionPostPone = 600000;
>
> public void onInit(List<? extends IndexCommit> commits) {
> // Note that commits.size() should normally be 1:
> onCommit(commits);
> }
>
> /**
> * delete commits after deletePostPone ms.
> */
> public void onCommit(List<? extends IndexCommit> commits) {
> // Note that commits.size() should normally be 2 (if not
> // called by onInit above):
> int size = commits.size();
> try {
> long lastCommitTimestamp = commits.get(commits.size() -
> 1).getTimestamp();
> for (int i = 0; i < size - 1; i++) {
> if (lastCommitTimestamp - commits.get(i).getTimestamp() >
> deletionPostPone) {
> commits.get(i).delete();
> }
> }
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> ----------------------------------
> indexWriterConfig.setIndexDeletionPolicy(new
> PostponeCommitDeletionPolicy());
> ----------------------------------
> and I use a time task(10 minutes) to reopen indexsearcher,but still read
> past EOF...the trace:
> java.io.IOException: read past EOF
> at
> org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:207)
> at
> org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:84)
> at
> org.apache.lucene.store.BufferedIndexInput.readInt(BufferedIndexInput.java:153)
> at
> org.apache.lucene.index.TermVectorsReader.checkValidFormat(TermVectorsReader.java:197)
> at
> org.apache.lucene.index.TermVectorsReader.<init>(TermVectorsReader.java:86)
> at
> org.apache.lucene.index.SegmentCoreReaders.openDocStores(SegmentCoreReaders.java:221)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:117)
> at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
> at
> org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:113)
> at
> org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:29)
> at
> org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:81)
> at
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
> at
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:75)
> at org.apache.lucene.index.IndexReader.open(IndexReader.java:421)
> at org.apache.lucene.index.IndexReader.open(IndexReader.java:281)
> at
> org.apache.lucene.search.IndexSearcher.<init>(IndexSearcher.java:89)
> at
> com.ableskysearch.migration.timertask.ReopenIndexSearcherTask.runAsPeriod(ReopenIndexSearcherTask.java:40)
>
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3724672.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
public class PostponeCommitDeletionPolicy implements IndexDeletionPolicy {
private final static long deletionPostPone = 600000;
public void onInit(List<? extends IndexCommit> commits) {
// Note that commits.size() should normally be 1:
onCommit(commits);
}
/**
* delete commits after deletePostPone ms.
*/
public void onCommit(List<? extends IndexCommit> commits) {
// Note that commits.size() should normally be 2 (if not
// called by onInit above):
int size = commits.size();
try {
long lastCommitTimestamp = commits.get(commits.size() -
1).getTimestamp();
for (int i = 0; i < size - 1; i++) {
if (lastCommitTimestamp - commits.get(i).getTimestamp() >
deletionPostPone) {
commits.get(i).delete();
}
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
----------------------------------
indexWriterConfig.setIndexDeletionPolicy(new
PostponeCommitDeletionPolicy());
----------------------------------
and I use a time task(10 minutes) to reopen indexsearcher,but still read
past EOF...the trace:
java.io.IOException: read past EOF
at
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:207)
at
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:39)
at org.apache.lucene.store.DataInput.readInt(DataInput.java:84)
at
org.apache.lucene.store.BufferedIndexInput.readInt(BufferedIndexInput.java:153)
at
org.apache.lucene.index.TermVectorsReader.checkValidFormat(TermVectorsReader.java:197)
at
org.apache.lucene.index.TermVectorsReader.<init>(TermVectorsReader.java:86)
at
org.apache.lucene.index.SegmentCoreReaders.openDocStores(SegmentCoreReaders.java:221)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:117)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:93)
at
org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:113)
at
org.apache.lucene.index.ReadOnlyDirectoryReader.<init>(ReadOnlyDirectoryReader.java:29)
at
org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:81)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:754)
at
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:75)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:421)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:281)
at
org.apache.lucene.search.IndexSearcher.<init>(IndexSearcher.java:89)
at
com.ableskysearch.migration.timertask.ReopenIndexSearcherTask.runAsPeriod(ReopenIndexSearcherTask.java:40)
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3724672.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
ok,thanks.
I modify my program like you suggest.But another problem appear:
java.lang.ArrayIndexOutOfBoundsException: -1
at
org.apache.lucene.index.TermInfosReader.seekEnum(TermInfosReader.java:203)
at
org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:273)
at
org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:210)
at
org.apache.lucene.index.SegmentReader.docFreq(SegmentReader.java:507)
at
org.apache.lucene.search.TermQuery$TermWeight$1.add(TermQuery.java:56)
at org.apache.lucene.util.ReaderUtil$Gather.run(ReaderUtil.java:77)
at org.apache.lucene.util.ReaderUtil$Gather.run(ReaderUtil.java:82)
at org.apache.lucene.util.ReaderUtil$Gather.run(ReaderUtil.java:66)
at
org.apache.lucene.search.TermQuery$TermWeight.<init>(TermQuery.java:53)
at
org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:198)
at
org.apache.lucene.search.BooleanQuery$BooleanWeight.<init>(BooleanQuery.java:176)
at
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:354)
at
org.apache.lucene.search.BooleanQuery$BooleanWeight.<init>(BooleanQuery.java:176)
at
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:354)
at
org.apache.lucene.search.Searcher.createNormalizedWeight(Searcher.java:168)
at
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:661)
at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:356)
at
com.ableskysearch.migration.search.IndexManagerImpl$1.getResultList(IndexManagerImpl.java:608)
It appear unfrequently.And can't search that time,but goes well soon.
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3721594.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Instead of .getVersion() you should use .getTimestamp()... version is
not "really" a timestamp. (Though, really, you should store your own
timestamp inside the commit userData, and retrieve that, instead...
the getTimestamp API will be deprecated in 3.6.0).
Also, you may need to implement onInit, in case you close/open a
writer while readers stay open, you still want to ensure the commits
are preserved.
Instead of using "present", I think you should set that to the time of
the last commit. Ie, you always compare older commits against the
timestamp of the most recent commit. This way you can use the same
function in onInit and onCommit.
Mike McCandless
http://blog.mikemccandless.com
On Thu, Feb 2, 2012 at 10:17 PM, superruiye <su...@gmail.com> wrote:
> eg,I implement IndexDeletionPolicy and the onCommit():
>
> public void onCommit(List<? extends IndexCommit> commits) {
> // Note that commits.size() should normally be 2 (if not
> // called by onInit above):
> int size = commits.size();
> long present = System.currentTimeMillis();
> for (int i = 0; i < size - 1; i++) {
> if (present - commits.get(i).getVersion() > deletionPostPone){
> //deletionPostPone=600000
> commits.get(i).delete();
> }
> }
> }
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3712006.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by superruiye <su...@gmail.com>.
eg,I implement IndexDeletionPolicy and the onCommit():
public void onCommit(List<? extends IndexCommit> commits) {
// Note that commits.size() should normally be 2 (if not
// called by onInit above):
int size = commits.size();
long present = System.currentTimeMillis();
for (int i = 0; i < size - 1; i++) {
if (present - commits.get(i).getVersion() > deletionPostPone){
//deletionPostPone=600000
commits.get(i).delete();
}
}
}
--
View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3712006.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Why read past EOF
Posted by Michael McCandless <lu...@mikemccandless.com>.
Right, you have to ensure (by using the "right" IndexDeletionPolicy)
that no commit is ever removed until all readers open against that
commit have been closed.
"Normally" the filesystem ensures this for us (protects still-open
files from being deleted), but NFS (unfortunately!) lacks such
semantics.
Persistent/SnapshotDeletionPolicy could in theory be used here... eg
you can pull a snapshot of the current commit, then call
IndexWriter.commit, then wait for all readers to reopen, then release
the snapshot. In theory that should work? You can make it time
based, eg wait 30 minutes and then release the snapshot, assuming your
readers all check for (and complete) reopen more frequently than every
30 minutes.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Jan 31, 2012 at 10:41 PM, superruiye <su...@gmail.com> wrote:
> Does it means I only to ensure reopen readers before deleted.I use default
> IndexDeletionPolicy: KeepOnlyLastCommitDeletionPolicy.And another two
> IndexDeletionPolicy,SnapshotDeletionPolicy and
> PersistentSnapshotDeletionPolicy,I am watching now.Are they useful to this
> problem?
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Why-read-past-EOF-tp3639401p3705542.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org