[
https://issues.apache.org/jira/browse/SOLR-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867218#comment-13867218
]
Michael McCandless commented on SOLR-5621:
------------------------------------------
+1 to do this in trunk, and give it time to bake.
A future cutover to SearcherLifetimeManager makes sense too; then Solr doesn't
need to load stored documents to get the "id" field to reference documents
anymore. Just use the searcher version + docID.
Refactoring code is a healthy and ongoing process in good open-source projects,
like ours. Yes, there is short-term risk of instability, but over time this
trades off for a stronger long-term design for Solr.
Solr should also be [more] per-segment, use Lucene Filters, etc.
> 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
> Fix For: 5.0
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
