[
https://issues.apache.org/jira/browse/LUCENE-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976031#action_12976031
]
Robert Muir commented on LUCENE-2837:
-------------------------------------
i noticed the comment about the shutting down of executorservice... can we just
make the executorservice arg mandatory for parallel?
in my opinion, whoever creates it should be responsible for shutting it down,
no one else.
so i don't like the dual mode where we sometimes make our own but you can set a
different one.
we don't clean up correctly at all wrt this in ParallelMultiShredder today in
my opinion.
> 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
>
>
> 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]
