er end of
>>>> optimize=81Mb,
>>>> after commit=40Mb, after writer close=40Mb
>>>> 2) initial=41Mb, before end of optimize=122Mb, after end of
>>>> optimize=104Mb,
>>>> after commit=104Mb,
ferent posts I assumed that a commit would have the same
>>> effect
>>> as a close as far as reclaiming disk space is concerned. however test
>>> cases
>>> 2 and 3 show that whether the reader is opened before or during the
>>> optimize
>>> we end up after
;
>> What is the reason why the commit nor closing the reader can get us back
>> to
>> nominal?
>> Do you recommend closing and recreating a new writer after an optimize?
>>
>> thanks
>> vincent
>>
>>
>> Michael McCandless-2 wrote:
>&
reating a new writer after an optimize?
>
> thanks
> vincent
>
>
> Michael McCandless-2 wrote:
>>
>> OK, I'll add that to the javadocs; thanks.
>>
>> But the fact that you weren't closing the old readers was probably
>> also tying up lots of
I'll add that to the javadocs; thanks.
>
> But the fact that you weren't closing the old readers was probably
> also tying up lots of disk space...
>
> Mike
>
--
View this message in context:
http://old.nabble.com/Searching-while-optimizing-tp26485138p26545384.h
ter is interruptible via Thread.interrupt(), but searching
>> currently is not. However, TimeLimitingCollector can be used to set a
>> timeout for searches.
>>
>> Mike
>>
>> -
>> To unsubscribe, e-m
; timeout for searches.
>
> Mike
>
> -----
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>
>
--
View thi
On Tue, Nov 24, 2009 at 9:08 AM, vsevel wrote:
> Hi, just to make sure I understand correctly... After an optimize, without
> any reader, my index takes 30Gb on the disk. Are you saying that if I can
> ensure there is only one reader at a time, it could take up to 120Gb on the
> disk if searching
t open a single reader).
>
> Mike
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Michael McCandless [mailto:luc...@mikemccandless.com]
>> Sent: Tuesday, November 24, 2009 11:00
e.apache.org
> Subject: Re: Searching while optimizing
>
> On Tue, Nov 24, 2009 at 1:44 AM, vsevel wrote:
> >
> > 1) correct: I am using IndexWriter.getReader(). I guess I was assuming
> that
> > was a privately owned object and I had no business dealing with its
On Tue, Nov 24, 2009 at 1:44 AM, vsevel wrote:
>
> 1) correct: I am using IndexWriter.getReader(). I guess I was assuming that
> was a privately owned object and I had no business dealing with its
> lifecycle. the api would be clearer to rename the operation createReader().
I just committed an ad
s refreshing a reader during an optimize? how can I avoid this behavior?
>> should I just deny searches while optimizing?
>>
>> question on the side: is there any way to interrupt a search that takes
>> too
>> long? for instance by setting a boolean from ano
to interrupt a search that takes too
> long? for instance by setting a boolean from another thread on the searcher
> currently performing the search.
>
> thanks,
> vincent
> --
> View this message in context:
> http://old.nabble.com
ead on the searcher
currently performing the search.
thanks,
vincent
--
View this message in context:
http://old.nabble.com/Searching-while-optimizing-tp26485138p26485138.html
Sent from the Lucene - Java Users mailing list archive at
15 matches
Mail list logo
