[
https://issues.apache.org/jira/browse/SOLR-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867007#comment-13867007
]
Tomás Fernández Löbbe commented on SOLR-5621:
---------------------------------------------
That's true, however I think it's good because it allows Solr to reuse Lucene's
components instead of duplicate the code. I understand that the SearcherManager
was not originally used because it didn't exist by the time Solr was created,
but now that it does (and AFAK it's a Lucene best practice for cases like this)
we should try to adopt it.
Also, I think it would allow Solr to also use Lucene's SearcherLifetimeManager
for searcher leases, which I think could allow Solr to use internal docids for
distributed search instead of the unique key. I know leases could be
implemented in Solr too without using the SearcherLifetimeManager, but that way
we continue duplicating functionality instead of using what's already built.
> Let Solr use Lucene's SeacherManager
> ------------------------------------
>
> Key: SOLR-5621
> URL: https://issues.apache.org/jira/browse/SOLR-5621
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 5.0
> Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-5621.patch
>
>
> It would be nice if Solr could take advantage of Lucene's SearcherManager and
> get rid of most of the logic related to managing Searchers in SolrCore.
> I've been taking a look at how possible it is to achieve this, and even if I
> haven't finish with the changes (there are some use cases that are still not
> working exactly the same) it looks like it is possible to do. Some things
> still could use a lot of improvement (like the realtime searcher management)
> and some other not yet implemented, like Searchers on deck or
> IndexReaderFactory
> I'm attaching an initial patch (many TODOs yet).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
