My client does not call my reader.reopen(), I have implemented a reload()
method off of my reader (void reload()), and it discards the internal reader
upon a reload. Due to another issue (an api issue with IndexReader, e.g. all
derived implementations have to reimplement reopen because it has to return
its instance even if there is nothing specific to do, kinda defeats the
purpose of object overriding)
Anyway, my system only calls myReader.reload() everytime the index "flips"
Re Mark's comment, does your test do both indexing and searching during the
duration of your run? How big is your index?
Thanks
-John
On Thu, May 29, 2008 at 10:29 AM, Michael Busch <[EMAIL PROTECTED]> wrote:
> Does your FilteredIndexReader.reopen() return a new instance of
> FilteredIndexReader in case the inner reader was updated (i. e.
> in!=newInner)?
>
>
> -Michael
>
>
> John Wang wrote:
>
>> Yes:
>>
>> IndexReader newInner=in.reopen();
>> if (in!=newInner)
>> {
>> in.close();
>> this.in=newInner;
>>
>> // code to clean up my data
>> _cache.clear();
>> _indexData.load(this, true);
>> init(_fieldConfig);
>> }
>>
>> if I change this code to:
>> try
>> {
>> this.in.close(); force close
>> }
>> catch(Exception e)
>> {
>> logger.warn(e.getMessage());
>> }
>> finally
>> {
>> this.in=newReader(); <-- new instance of IndexReader
>> _cache.clear();
>> _indexData.load(this, true);
>> init(_fieldConfig);
>> }
>>
>> fixes my leak.
>>
>> -John
>>
>> On Thu, May 29, 2008 at 12:35 AM, Michael Busch <[EMAIL PROTECTED]>
>> wrote:
>>
>> Could you share some details about how you implemented reopen() in your
>>> reader?
>>>
>>> -Michael
>>>
>>>
>>> John Wang wrote:
>>>
>>> Yes, I do close the old reader.
>>>> I have a large index, my system is doing real time updates: 1 thread
>>>> writing
>>>> batches of updates to the index, after each index update, it updates the
>>>> reader. I have two readers open always, one is serving the search
>>>> requests,
>>>> while the other updates and the two flips. Reader update implies index
>>>> reopen here.
>>>>
>>>> I am using my implementation of a FilteredIndexReader.
>>>>
>>>> Index leaks very slowly, but obvious.
>>>>
>>>> No, I am not able to provide heap dumps.
>>>>
>>>> -John
>>>>
>>>> On Wed, May 28, 2008 at 4:23 PM, Mark Miller <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>> As someone that has done a lot of reopens, I can vouch there is no leak
>>>>
>>>>> under simple, normal usage. Are you sure your closing the original
>>>>> reader
>>>>> after getting the reopened reference?
>>>>>
>>>>>
>>>>> Michael Busch wrote:
>>>>>
>>>>> Hi John,
>>>>>
>>>>>> hmm not good. I will take a look. It has probably to do with the
>>>>>> reference
>>>>>> counting. Are you doing anything special? E. g. do you have own reader
>>>>>> implementations that you call reopen() on? What kinds of readers are
>>>>>> you
>>>>>> using?
>>>>>>
>>>>>> Are you maybe able to provide a heapdump?
>>>>>>
>>>>>> -Michael
>>>>>>
>>>>>> John Wang wrote:
>>>>>>
>>>>>> Hi:
>>>>>>
>>>>>>> We are experiencing memory leak with calling IndexReader.reopen().
>>>>>>>
>>>>>>> From eyeballing the lucene source code, I am seeing normCache is not
>>>>>>> cleared.
>>>>>>>
>>>>>>>
>>>>>>> Anyone else experiencing this?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -John
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
