[
https://issues.apache.org/jira/browse/LUCENE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182082#comment-13182082
]
Shay Banon edited comment on LUCENE-3644 at 1/7/12 8:22 PM:
------------------------------------------------------------
I just saw this thread, and would like to respond to @Uwe as I think he is
completely wrong here. Its perfectly fine to have listeners in this case. If
you are implementing a cache based on core readers (think custom filter cache
for example), its basically the only sane way to do it (and not have to handle
weak references which is bad on GC and error prone with complex keys). And
Lucene should allow for that.
I don't think the separation to segment core listener and index reader listener
is the best solution here, since it exposes "too much info" to the user (having
to deal with different reader cases, check FieldCacheImpl for example). I don't
really mind it, since in my case I only work on low level Segment case (which
is the sane way to work when you do NRT) and can handle it, but not sure its
best in a general usability wise case. What the user want is: here is a reader,
which I cache base on it, and here is a listener, call me back when that
listener is no longer valid.
was (Author: kimchy):
I just saw this thread, and would like to respond to @Uwe as I think he is
completely wrong here. Its perfectly fine to have listeners in this case. If
you are implementing a cache based on core readers (think custom filter cache
for example), its basically the only sane way to do it (and not have to handle
weak references which is bad on GC and error prone with complex keys). And
Lucene should allow for that.
I don't think the separation to segment core listener and index reader listener
is the best solution here, since it exposes "too much info" to the user (having
to deal with different reader cases, check FieldCacheImpl for example). I don't
really mind it, since in my case I only work on low level Segment case (which
is the sane way to work when you do NRT) and can handle it, but not sure its
best in a general usability wise case. What the user want is: here is a reader,
which I case base on it, and here is a listener, call me back when that
listener is no longer valid.
> problems with IR's readerFinishedListener
> -----------------------------------------
>
> Key: LUCENE-3644
> URL: https://issues.apache.org/jira/browse/LUCENE-3644
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Robert Muir
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3644.patch, LUCENE-3644.patch, LUCENE-3644.patch
>
>
> There are two major problems:
> 1. The listener api does not really apply all indexreaders. for example
> segmentreaders dont fire it on close, only segmentcorereaders. this is wrong,
> a segmentcorereader is *not* an indexreader. Furthermore, if you register it
> on a top-level reader you get events for anything under the reader tree
> (sometimes, unless they are segmentreaders as mentioned above, where it
> doesnt work correctly at all).
> 2. Furthermore your listener is 'passed along' in a viral fashion from
> clone() and reopen(). This means for example, if you are trying to listen to
> readers in NRT search you are just accumulating reader listeners, all
> potentially keeping references to old indexreaders (because, in order to deal
> with #1 your listener must 'keep' a reference to the IR it was registered on,
> so it can check if thats *really* the one).
> We should discuss how to fix #1.
> I will create a patch for #2 shortly and commit it, its just plain wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
