[
https://issues.apache.org/jira/browse/SOLR-5621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867147#comment-13867147
]
Uwe Schindler commented on SOLR-5621:
-------------------------------------
Hi Yonik,
please don't be unfair to Tomás: You might be right, that this is too risky for
the stable branch, but we have still LuSolr trunk, so I see no problem
committing this (once its done) to Solr trunk. It can then bake for long time,
until Solr 5.0 is released. You have to recognize that he opened this issue
with affects/fix version 5.0.
As Tomás describes:
bq. 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.
This is a perfect use-case, although I am not sure if this would be easy. But a
Job for another followup issue for Solr 5.0.
bq. It was supposed to be. Hasn't exactly worked out well IMO.
You are the only one that uses this statement. In my opinion the "same Apache
project" worked perfectly:
- We got a lot of additional per-segment stuff in Solr.
- I helped a lot to get lot's of API changes in Lucene into Solr, e.g. the
refactoring of Document, IndexReader. Others helped with TermsEnum,...
- Better Analyzer support in Solr. Users don't need to write factories for
stuff that's already in Lucene. Just plugin e.g. lucene-analysis-kuromoji into
your lib/ folder and it automatically works thaks to SPI. If we would still
have facories solely in Sold, one would have to write factories for all Lucene
modules or we would need to ship with them with Solr Core (so dependiing on
stuff like kuromoji the user don't needs).
- All codec support was mostly written by (originally) Lucene committers.
With your statement, you are the only person who fights against working
together even more! Some examples:
- The Facet module improved so much, why not allow to use it from Solr? To me
it looks like you are against. Just because you would need to configure in the
schema which fields you want facet on! The current Solr facetting uninverting
all stuff is a disaster performance- and memory wise
- Extracting factories from Solr: No you were against, because your enemy ES
could use it - But we did it anyhow. That's good! And ES did not yet completely
took over your code, so where is the problem?
With the given possibilities for improvements and better maintainability of
this code we are on the right path. I am sure with the new code maybe the crazy
Solr failures hitting us all the time from Solr tests maybe get better (you
know, the damnful: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=59
closes=58).
Uwe
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
