Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Lucene: Java-User

Query in IndexWriter.deleteDocuments(Term term)

 

 

Lucene java-user RSS feed   Index | Next | Previous | View Threaded


ajaygargnsit at gmail

Jul 25, 2008, 9:17 PM

Post #1 of 10 (406 views)
Permalink
Query in IndexWriter.deleteDocuments(Term term)

Hi all.

This may seem a longish and informal mail, but do correct me if my
assumptions are wrong anywhere, otherwise my actual doubt will make no
sense.

Say I opened an IndexWriter on an initially empty directory, using
autocommit = true. Now, what I do is add and delete documents randomly. I
set "x" as maxBufferedDocs and "y" as maxBufferedDeleteTerms (x < y).

IndexWritrer starts its work. Now, I perfom the following sequences :

STAGE 1 :
Add "x-2" documents one after the another. Total docs in
memory = x-2 (1)
Delete 3 docs from memory Total docs
in memory = x-5 (2)
Add 5 docs one after another Total docs
in memory = x (3)

STAGE 2 :
A flush happens, sice maxBufferedDocs reached. Total docs in
memory = 0 (4)
Thus, it is also a commit.

STAGE 3 :
Add x-10 docs one after other Total docs
in memory = x-10 (5)


NOW ... I call deleteDocuments(Term term), which has potential matches at
two places :
a) x-15 (out of x-10) documents currently residing in memory.
b) x-20 (out of x) documents currently in the index directory.
(6)

IndexWriter.close() is called
(7)


Now, my question is, will the index contain
(i) a total of (x) + (x-10) - (x-15) documents
(ii) a total of (x) + (x-10) - (x-20) documents
(iii) a total of (x) + (x-10) - (x-15) - (x-20) documents


Secondly, will the answer change had I opened the IndexWriter in autocommit
= false mode?

Several other permutations of (autocommit mode), (points of flush call),
(points of close call) exist, but I guess I will be fine if I get the answer
to the first question itself. A little explanation will be highly obliged.

Looking forward to responses.

Ajay Garg
--
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18662995.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


lucene at mikemccandless

Jul 26, 2008, 2:41 AM

Post #2 of 10 (391 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

java_is_everything wrote:

>
> Hi all.
>
> This may seem a longish and informal mail, but do correct me if my
> assumptions are wrong anywhere, otherwise my actual doubt will make no
> sense.
>
> Say I opened an IndexWriter on an initially empty directory, using
> autocommit = true. Now, what I do is add and delete documents
> randomly. I
> set "x" as maxBufferedDocs and "y" as maxBufferedDeleteTerms (x < y).
>
> IndexWritrer starts its work. Now, I perfom the following sequences :
>
> STAGE 1 :
> Add "x-2" documents one after the another. Total docs
> in
> memory = x-2 (1)
> Delete 3 docs from memory
> Total docs
> in memory = x-5 (2)
> Add 5 docs one after another
> Total docs
> in memory = x (3)
>
> STAGE 2 :
> A flush happens, sice maxBufferedDocs reached. Total docs in
> memory = 0 (4)

One correction here: the added doc count that triggers a flush does
*not* measure deletions. So, in your step (3) above, after having
added 2 of the 5 docs, IW will flush. Then it has 3 added docs
buffered in RAM.

> Thus, it is also a commit.

Assuming you're talking about trunk at this point (not 2.3), because
only trunk distinguishes commit() vs flush(): there's no guarantee
exactly when IW does a commit() when autoCommit is true. Also,
autoCommit is deprecated, meaning in 3.0 it will be hardwired to
false, so your application must commit() or close() when it's necessary.

> STAGE 3 :
> Add x-10 docs one after other
> Total docs
> in memory = x-10 (5)

Actually x-7 in memory now.

> NOW ... I call deleteDocuments(Term term), which has potential
> matches at
> two places :
> a) x-15 (out of x-10) documents currently residing in memory.
> b) x-20 (out of x) documents currently in the index directory.
> (6)
>
> IndexWriter.close() is called
> (7)
>
>
> Now, my question is, will the index contain
> (i) a total of (x) + (x-10) - (x-15) documents
> (ii) a total of (x) + (x-10) - (x-20) documents
> (iii) a total of (x) + (x-10) - (x-15) - (x-20) documents

Index will contain (iii), corrected to (x) + (x-7) - (x-15) - (x-20).
Ie the deletion always applies to any documents, flushed or buffered
in RAM. The deletion is fully independent of what buffering IW is
doing.

> Secondly, will the answer change had I opened the IndexWriter in
> autocommit
> = false mode?

No, you get the same result. autoCommit simply affects *when* the
changes become visible/durable to an external reader, not what changes
occur. Any series of changes using an IW will produce the same final
result regardless of autoCommit, assuming we're not talking about JRE/
machine's crashing, etc.

> Several other permutations of (autocommit mode), (points of flush
> call),
> (points of close call) exist, but I guess I will be fine if I get
> the answer
> to the first question itself. A little explanation will be highly
> obliged.

autoCommit, points of flushing, points of committing, points of
merging, etc, should be fully independent of what changes (add/
deletes) you are doing.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


ajaygargnsit at gmail

Jul 26, 2008, 3:40 AM

Post #3 of 10 (392 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Thanks Mike. That was quite explanatory. A couple of doubts :

1. The deletions apply to buffered as well as stored-in-RAM documents.
Right. So, if the index directory contains 1 document that matches a
deleteDocument query, and 1 document in RAM that contains the same
deleteDocument query, then, will the document-in-index-directory be deleted
immediately, or when a flush is called. (It seems logical, that irrespective
of the location of document, "actual" deletion occurs only when a flush is
called .. just need to be doubly sure ...)

2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is the
next version heading straight to 3.0 ??? (Sorry, if this question seems to
be a little out of context of the current thread)

Looking forward to a reply.

Thanks
Ajay Garg

Michael McCandless-2 wrote:
>
>
> java_is_everything wrote:
>
>>
>> Hi all.
>>
>> This may seem a longish and informal mail, but do correct me if my
>> assumptions are wrong anywhere, otherwise my actual doubt will make no
>> sense.
>>
>> Say I opened an IndexWriter on an initially empty directory, using
>> autocommit = true. Now, what I do is add and delete documents
>> randomly. I
>> set "x" as maxBufferedDocs and "y" as maxBufferedDeleteTerms (x < y).
>>
>> IndexWritrer starts its work. Now, I perfom the following sequences :
>>
>> STAGE 1 :
>> Add "x-2" documents one after the another. Total docs
>> in
>> memory = x-2 (1)
>> Delete 3 docs from memory
>> Total docs
>> in memory = x-5 (2)
>> Add 5 docs one after another
>> Total docs
>> in memory = x (3)
>>
>> STAGE 2 :
>> A flush happens, sice maxBufferedDocs reached. Total docs in
>> memory = 0 (4)
>
> One correction here: the added doc count that triggers a flush does
> *not* measure deletions. So, in your step (3) above, after having
> added 2 of the 5 docs, IW will flush. Then it has 3 added docs
> buffered in RAM.
>
>> Thus, it is also a commit.
>
> Assuming you're talking about trunk at this point (not 2.3), because
> only trunk distinguishes commit() vs flush(): there's no guarantee
> exactly when IW does a commit() when autoCommit is true. Also,
> autoCommit is deprecated, meaning in 3.0 it will be hardwired to
> false, so your application must commit() or close() when it's necessary.
>
>> STAGE 3 :
>> Add x-10 docs one after other
>> Total docs
>> in memory = x-10 (5)
>
> Actually x-7 in memory now.
>
>> NOW ... I call deleteDocuments(Term term), which has potential
>> matches at
>> two places :
>> a) x-15 (out of x-10) documents currently residing in memory.
>> b) x-20 (out of x) documents currently in the index directory.
>> (6)
>>
>> IndexWriter.close() is called
>> (7)
>>
>>
>> Now, my question is, will the index contain
>> (i) a total of (x) + (x-10) - (x-15) documents
>> (ii) a total of (x) + (x-10) - (x-20) documents
>> (iii) a total of (x) + (x-10) - (x-15) - (x-20) documents
>
> Index will contain (iii), corrected to (x) + (x-7) - (x-15) - (x-20).
> Ie the deletion always applies to any documents, flushed or buffered
> in RAM. The deletion is fully independent of what buffering IW is
> doing.
>
>> Secondly, will the answer change had I opened the IndexWriter in
>> autocommit
>> = false mode?
>
> No, you get the same result. autoCommit simply affects *when* the
> changes become visible/durable to an external reader, not what changes
> occur. Any series of changes using an IW will produce the same final
> result regardless of autoCommit, assuming we're not talking about JRE/
> machine's crashing, etc.
>
>> Several other permutations of (autocommit mode), (points of flush
>> call),
>> (points of close call) exist, but I guess I will be fine if I get
>> the answer
>> to the first question itself. A little explanation will be highly
>> obliged.
>
> autoCommit, points of flushing, points of committing, points of
> merging, etc, should be fully independent of what changes (add/
> deletes) you are doing.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>
>
>

--
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18665652.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


lucene at mikemccandless

Jul 26, 2008, 5:12 AM

Post #4 of 10 (389 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Ajay Garg wrote:

> Thanks Mike. That was quite explanatory. A couple of doubts:

You're welcome!

> 1. The deletions apply to buffered as well as stored-in-RAM documents.
> Right. So, if the index directory contains 1 document that matches a
> deleteDocument query, and 1 document in RAM that contains the same
> deleteDocument query, then, will the document-in-index-directory be
> deleted
> immediately, or when a flush is called. (It seems logical, that
> irrespective
> of the location of document, "actual" deletion occurs only when a
> flush is
> called .. just need to be doubly sure ...)

Well ... the "actual" deletion (visible to an IndexReader that opens
the index) is only guaranteed to be performed if you call commit()
(trunk) or close() (2.3, trunk) on the IW.

First, deleted docIDs, terms and queries are simply buffered in RAM.
Then at some point (no guarantee on when) they are flushed into per-
segment .del files in the directory, but, these del files are
"unreferenced" (by a segments_N file) until commit() or close() is
called.

> 2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is
> the
> next version heading straight to 3.0 ??? (Sorry, if this question
> seems to
> be a little out of context of the current thread)

The current plan is to have a 2.4 release next, then a 2.9 release and
finally 3.0. It's spelled out a bit here:

http://wiki.apache.org/lucene-java/Java_1.5_Migration

But there are no dates attached to those bullets!

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


ajaygargnsit at gmail

Jul 26, 2008, 6:27 AM

Post #5 of 10 (385 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

So commit() will be available from 2.4 onwards??

Michael McCandless-2 wrote:
>
>
> Ajay Garg wrote:
>
>> Thanks Mike. That was quite explanatory. A couple of doubts:
>
> You're welcome!
>
>> 1. The deletions apply to buffered as well as stored-in-RAM documents.
>> Right. So, if the index directory contains 1 document that matches a
>> deleteDocument query, and 1 document in RAM that contains the same
>> deleteDocument query, then, will the document-in-index-directory be
>> deleted
>> immediately, or when a flush is called. (It seems logical, that
>> irrespective
>> of the location of document, "actual" deletion occurs only when a
>> flush is
>> called .. just need to be doubly sure ...)
>
> Well ... the "actual" deletion (visible to an IndexReader that opens
> the index) is only guaranteed to be performed if you call commit()
> (trunk) or close() (2.3, trunk) on the IW.
>
> First, deleted docIDs, terms and queries are simply buffered in RAM.
> Then at some point (no guarantee on when) they are flushed into per-
> segment .del files in the directory, but, these del files are
> "unreferenced" (by a segments_N file) until commit() or close() is
> called.
>
>> 2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is
>> the
>> next version heading straight to 3.0 ??? (Sorry, if this question
>> seems to
>> be a little out of context of the current thread)
>
> The current plan is to have a 2.4 release next, then a 2.9 release and
> finally 3.0. It's spelled out a bit here:
>
> http://wiki.apache.org/lucene-java/Java_1.5_Migration
>
> But there are no dates attached to those bullets!
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>
>
>

--
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18666813.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


ajaygargnsit at gmail

Jul 26, 2008, 6:31 AM

Post #6 of 10 (386 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Pardon me. But will commit() be "code-fully" equal to calling close()
followed by reinstantiating IW with create=false ??? If the above is indeed
true, I can very well begin with my work.

I ask this, because I plan to work within a fortnight, and 2.4 is still
someway away, and the primary reason I am porting to 2.3.2 (from 2.0.0), is
to have explicit commit() control in our hands.


Ajay Garg wrote:
>
> So commit() will be available from 2.4 onwards??
>
> Michael McCandless-2 wrote:
>>
>>
>> Ajay Garg wrote:
>>
>>> Thanks Mike. That was quite explanatory. A couple of doubts:
>>
>> You're welcome!
>>
>>> 1. The deletions apply to buffered as well as stored-in-RAM documents.
>>> Right. So, if the index directory contains 1 document that matches a
>>> deleteDocument query, and 1 document in RAM that contains the same
>>> deleteDocument query, then, will the document-in-index-directory be
>>> deleted
>>> immediately, or when a flush is called. (It seems logical, that
>>> irrespective
>>> of the location of document, "actual" deletion occurs only when a
>>> flush is
>>> called .. just need to be doubly sure ...)
>>
>> Well ... the "actual" deletion (visible to an IndexReader that opens
>> the index) is only guaranteed to be performed if you call commit()
>> (trunk) or close() (2.3, trunk) on the IW.
>>
>> First, deleted docIDs, terms and queries are simply buffered in RAM.
>> Then at some point (no guarantee on when) they are flushed into per-
>> segment .del files in the directory, but, these del files are
>> "unreferenced" (by a segments_N file) until commit() or close() is
>> called.
>>
>>> 2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is
>>> the
>>> next version heading straight to 3.0 ??? (Sorry, if this question
>>> seems to
>>> be a little out of context of the current thread)
>>
>> The current plan is to have a 2.4 release next, then a 2.9 release and
>> finally 3.0. It's spelled out a bit here:
>>
>> http://wiki.apache.org/lucene-java/Java_1.5_Migration
>>
>> But there are no dates attached to those bullets!
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
>> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18666853.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


lucene at mikemccandless

Jul 26, 2008, 10:06 AM

Post #7 of 10 (381 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Yes.

Mike

Ajay Garg wrote:

>
> So commit() will be available from 2.4 onwards??
>
> Michael McCandless-2 wrote:
>>
>>
>> Ajay Garg wrote:
>>
>>> Thanks Mike. That was quite explanatory. A couple of doubts:
>>
>> You're welcome!
>>
>>> 1. The deletions apply to buffered as well as stored-in-RAM
>>> documents.
>>> Right. So, if the index directory contains 1 document that matches a
>>> deleteDocument query, and 1 document in RAM that contains the same
>>> deleteDocument query, then, will the document-in-index-directory be
>>> deleted
>>> immediately, or when a flush is called. (It seems logical, that
>>> irrespective
>>> of the location of document, "actual" deletion occurs only when a
>>> flush is
>>> called .. just need to be doubly sure ...)
>>
>> Well ... the "actual" deletion (visible to an IndexReader that opens
>> the index) is only guaranteed to be performed if you call commit()
>> (trunk) or close() (2.3, trunk) on the IW.
>>
>> First, deleted docIDs, terms and queries are simply buffered in RAM.
>> Then at some point (no guarantee on when) they are flushed into per-
>> segment .del files in the directory, but, these del files are
>> "unreferenced" (by a segments_N file) until commit() or close() is
>> called.
>>
>>> 2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is
>>> the
>>> next version heading straight to 3.0 ??? (Sorry, if this question
>>> seems to
>>> be a little out of context of the current thread)
>>
>> The current plan is to have a 2.4 release next, then a 2.9 release
>> and
>> finally 3.0. It's spelled out a bit here:
>>
>> http://wiki.apache.org/lucene-java/Java_1.5_Migration
>>
>> But there are no dates attached to those bullets!
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
>> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18666813.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


lucene at mikemccandless

Jul 26, 2008, 10:07 AM

Post #8 of 10 (384 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Ajay Garg wrote:

> Pardon me. But will commit() be "code-fully" equal to calling close()
> followed by reinstantiating IW with create=false ??? If the above is
> indeed
> true, I can very well begin with my work.

Yes, commit() can be seen as achieving exactly the same as close() and
opening a new IndexWriter.

> I ask this, because I plan to work within a fortnight, and 2.4 is
> still
> someway away, and the primary reason I am porting to 2.3.2 (from
> 2.0.0), is
> to have explicit commit() control in our hands.

OK but 2.3.2 doesn't have commit yet.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


ajaygargnsit at gmail

Jul 27, 2008, 9:25 PM

Post #9 of 10 (344 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Thanks Mike.

Yes, I know, 2.3.2 doesn't have commit(). That's why, I asked whether commit
= close + new IndexWriter, because then I can write a commit() method,
encapslating close() + new IndexWriter.

Thanks a ton for the prompt replies..

Ajay Garg

Michael McCandless-2 wrote:
>
>
> Ajay Garg wrote:
>
>> Pardon me. But will commit() be "code-fully" equal to calling close()
>> followed by reinstantiating IW with create=false ??? If the above is
>> indeed
>> true, I can very well begin with my work.
>
> Yes, commit() can be seen as achieving exactly the same as close() and
> opening a new IndexWriter.
>
>> I ask this, because I plan to work within a fortnight, and 2.4 is
>> still
>> someway away, and the primary reason I am porting to 2.3.2 (from
>> 2.0.0), is
>> to have explicit commit() control in our hands.
>
> OK but 2.3.2 doesn't have commit yet.
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>
>
>

--
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18683927.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org


lucene at mikemccandless

Jul 28, 2008, 2:17 AM

Post #10 of 10 (338 views)
Permalink
Re: Query in IndexWriter.deleteDocuments(Term term) [In reply to]

Ahh gotchya, OK.

Mike

Ajay Garg wrote:

>
> Thanks Mike.
>
> Yes, I know, 2.3.2 doesn't have commit(). That's why, I asked
> whether commit
> = close + new IndexWriter, because then I can write a commit() method,
> encapslating close() + new IndexWriter.
>
> Thanks a ton for the prompt replies..
>
> Ajay Garg
>
> Michael McCandless-2 wrote:
>>
>>
>> Ajay Garg wrote:
>>
>>> Pardon me. But will commit() be "code-fully" equal to calling
>>> close()
>>> followed by reinstantiating IW with create=false ??? If the above is
>>> indeed
>>> true, I can very well begin with my work.
>>
>> Yes, commit() can be seen as achieving exactly the same as close()
>> and
>> opening a new IndexWriter.
>>
>>> I ask this, because I plan to work within a fortnight, and 2.4 is
>>> still
>>> someway away, and the primary reason I am porting to 2.3.2 (from
>>> 2.0.0), is
>>> to have explicit commit() control in our hands.
>>
>> OK but 2.3.2 doesn't have commit yet.
>>
>> Mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
>> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18683927.html
> Sent from the Lucene - Java Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-user-help[at]lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe[at]lucene.apache.org
For additional commands, e-mail: java-user-help[at]lucene.apache.org

Lucene java-user RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.