[
https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977677#action_12977677
]
Simon Willnauer commented on LUCENE-2837:
-----------------------------------------
Mike that patch looks good to me. I just have one small comment about the
executor service. You stated that the user has to shutdown the service upon
IS#close(). This is absolutely the recommended way but I see a little risk for
people calling ExecutorService#shutdownNow() which interrupts the executing
threads and can cause a AlreadyClosedException down in one of our NIO
Directories if there are still searches going on etc. I don't think this is
super important but I would point it out in the JDoc to give folks a heads-up.
Thoughts?
simon
> Collapse Searcher/Searchable/IndexSearcher; remove contrib/remote; merge PMS
> into IndexSearcher
> -----------------------------------------------------------------------------------------------
>
> Key: LUCENE-2837
> URL: https://issues.apache.org/jira/browse/LUCENE-2837
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2837.patch, LUCENE-2837.patch
>
>
> We've discussed cleaning up our *Searcher stack for some time... I
> think we should try to do this before releasing 4.0.
> So I'm attaching an initial patch which:
> * Removes Searcher, Searchable, absorbing all their methods into
> IndexSearcher
> * Removes contrib/remote
> * Removes MultiSearcher
> * Absorbs ParallelMultiSearcher into IndexSearcher (ie you can now
> pass useThreads=true, or a custom ES to the ctor)
> The patch is rough -- I just ripped stuff out, did search/replace to
> IndexSearcher, etc. EG nothing is directly testing using threads with
> IndexSearcher, but before committing I think we should add a
> newSearcher to LuceneTestCase, which randomly chooses whether the
> searcher uses threads, and cutover tests to use this instead of making
> their own IndexSearcher.
> I think MultiSearcher has a useful purpose, but as it is today it's
> too low-level, eg it shouldn't be involved in rewriting queries: the
> Query.combine method is scary. Maybe in its place we make a higher
> level class, with limited API, that's able to federate search across
> multiple IndexSearchers? It'd also be able to optionally use thread
> per IndexSearcher.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
