[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org