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 John Wang <jo...@gmail.com> on 2008/06/29 17:51:55 UTC
Pooling indexReader
Hi:
I had some code to do indexReader pooling to avoid open and close on a
large index when doing lotsa searches. So I had a FilteredIndexReader proxy
that overrides the doClose method to do nothing, and when I really want to
close it, I call super.doClose(). This patter worked well for me prior to
2.3. With 2.3, the close is doing the reference counting out side of
doClose, and since close is final, my pattern is broken.
Am I using the api incorrectly? how would I accomplish this task?
Thanks
-John
Re: Pooling indexReader
Posted by Michael McCandless <lu...@mikemccandless.com>.
I don't see why close must be final; I think we could/should relax that?
But: I think your situation is perfect for incRef(). That method
declares that someone is still using the IndexReader (until the
corresponding decRef() is called).
Mike
John Wang wrote:
> Hi Mike:
> Thanks for the reply!
>
> The reason my pattern wouldn't work is because my doClose impl does
> nothing to avoid the actual closing and then later my "index
> updater" will
> do the actual closing. The problem is although my doClose is called,
> the
> reference is decremented to 0, and ensureOpen fails upon re-use of the
> indexReader. Prior to 2.3.1, my pattern worked because of lack the
> reference
> counting logic.
>
> I will check on how decRef/incRef would work in my case. Seems a
> bit
> "back-door"-ish. :)
>
> Do you think making IndexReader.close non-final is a possibility,
> cuz
> that would solve my problem.
>
> Thanks
>
> -John
>
> On Mon, Jun 30, 2008 at 2:07 AM, Michael McCandless <
> lucene@mikemccandless.com> wrote:
>
>>
>> It's true there is now reference counting logic to determine when
>> it's
>> really time to close an IndexReader, but, at that point doClose()
>> is still
>> called so your custom logic should still be running, right? It
>> seems like
>> your pattern ought to still be working?
>>
>> If not, another alternative might be to override decRef() with your
>> own
>> logic, or, you could externally hold your own reference to the
>> reader (call
>> its incRef()) and then decRef() it when you're done. That would
>> probably be
>> cleanest...
>>
>> Mike
>>
>>
>> On Jun 29, 2008, at 11:51 AM, John Wang wrote:
>>
>> Hi:
>>> I had some code to do indexReader pooling to avoid open and close
>>> on a
>>> large index when doing lotsa searches. So I had a
>>> FilteredIndexReader
>>> proxy
>>> that overrides the doClose method to do nothing, and when I really
>>> want to
>>> close it, I call super.doClose(). This patter worked well for me
>>> prior to
>>> 2.3. With 2.3, the close is doing the reference counting out side of
>>> doClose, and since close is final, my pattern is broken.
>>>
>>> Am I using the api incorrectly? how would I accomplish this task?
>>>
>>> Thanks
>>>
>>> -John
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Pooling indexReader
Posted by John Wang <jo...@gmail.com>.
Hi Mike:
Thanks for the reply!
The reason my pattern wouldn't work is because my doClose impl does
nothing to avoid the actual closing and then later my "index updater" will
do the actual closing. The problem is although my doClose is called, the
reference is decremented to 0, and ensureOpen fails upon re-use of the
indexReader. Prior to 2.3.1, my pattern worked because of lack the reference
counting logic.
I will check on how decRef/incRef would work in my case. Seems a bit
"back-door"-ish. :)
Do you think making IndexReader.close non-final is a possibility, cuz
that would solve my problem.
Thanks
-John
On Mon, Jun 30, 2008 at 2:07 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
>
> It's true there is now reference counting logic to determine when it's
> really time to close an IndexReader, but, at that point doClose() is still
> called so your custom logic should still be running, right? It seems like
> your pattern ought to still be working?
>
> If not, another alternative might be to override decRef() with your own
> logic, or, you could externally hold your own reference to the reader (call
> its incRef()) and then decRef() it when you're done. That would probably be
> cleanest...
>
> Mike
>
>
> On Jun 29, 2008, at 11:51 AM, John Wang wrote:
>
> Hi:
>> I had some code to do indexReader pooling to avoid open and close on a
>> large index when doing lotsa searches. So I had a FilteredIndexReader
>> proxy
>> that overrides the doClose method to do nothing, and when I really want to
>> close it, I call super.doClose(). This patter worked well for me prior to
>> 2.3. With 2.3, the close is doing the reference counting out side of
>> doClose, and since close is final, my pattern is broken.
>>
>> Am I using the api incorrectly? how would I accomplish this task?
>>
>> Thanks
>>
>> -John
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
Re: Pooling indexReader
Posted by Michael McCandless <lu...@mikemccandless.com>.
It's true there is now reference counting logic to determine when it's
really time to close an IndexReader, but, at that point doClose() is
still called so your custom logic should still be running, right? It
seems like your pattern ought to still be working?
If not, another alternative might be to override decRef() with your
own logic, or, you could externally hold your own reference to the
reader (call its incRef()) and then decRef() it when you're done.
That would probably be cleanest...
Mike
On Jun 29, 2008, at 11:51 AM, John Wang wrote:
> Hi:
> I had some code to do indexReader pooling to avoid open and close
> on a
> large index when doing lotsa searches. So I had a
> FilteredIndexReader proxy
> that overrides the doClose method to do nothing, and when I really
> want to
> close it, I call super.doClose(). This patter worked well for me
> prior to
> 2.3. With 2.3, the close is doing the reference counting out side of
> doClose, and since close is final, my pattern is broken.
>
> Am I using the api incorrectly? how would I accomplish this task?
>
> Thanks
>
> -John
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org