[ 
https://issues.apache.org/jira/browse/LUCENE-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505090#comment-13505090
 ] 

Michael McCandless commented on LUCENE-4566:
--------------------------------------------

Why do we need afterClose in the listener?  It seems like the app can handle 
this itself?  I think for NRTManager we should just keep using the protected 
method ...

I think we don't need a protected method afterRefresh?  It should just be 
private, and it invokes the listeners?

Can we just use sync'd list for the listeners (eg like SegmentCoreReader's 
listeners)?
                
> SearcherManager.afterRefresh() issues
> -------------------------------------
>
>                 Key: LUCENE-4566
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4566
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: selckin
>            Priority: Minor
>         Attachments: LUCENE-4566-double-listeners.patch, LUCENE-4566.patch
>
>
> 1) ReferenceManager.doMaybeRefresh seems to call afterRefresh even if it 
> didn't refresh/swap, (when newReference == null)
> 2) It would be nice if users were allowed to override 
> SearcherManager.afterRefresh() to get notified when a new searcher is in 
> action.
> But SearcherManager and ReaderManager are final, while NRTManager is not.
> The only way to currently hook into when a new searched is created is using 
> the factory, but if you wish to do some async task then, there are no 
> guarantees that acquire() will return the new searcher, so you have to pass 
> it around and incRef manually. While if allowed to hook into afterRefresh you 
> can just rely on acquire()  & existing infra you have around it to give you 
> the latest one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to