FAQ
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

Search Discussions

  • Michael McCandless at Jun 30, 2008 at 9:08 am
    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
  • John Wang at Jun 30, 2008 at 5:17 pm
    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 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
  • Michael McCandless at Jun 30, 2008 at 10:16 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-user @
categorieslucene
postedJun 29, '08 at 3:52p
activeJun 30, '08 at 10:16p
posts4
users2
websitelucene.apache.org

2 users in discussion

John Wang: 2 posts Michael McCandless: 2 posts

People

Translate

site design / logo © 2022 Grokbase