Based on the functionality diff, Apache Solr Search Integration explicitly sets the <luceneMatchVersion> directive for the Solr 3.x config files. The relevant discussion surrounding this is highlighted below:

#1392940: create a 3.x solrconfig.xml that sets luceneMatchVersion

Comments

pwolanin’s picture

This is suggested as the best practice, but note that because the default merge policy changed in lucene setting the merge policy needs to be set to make it the same for both configs.

cpliakas’s picture

Component: Code » solrconfig.xml

Adding new component flag.

drunken monkey’s picture

Component: solrconfig.xml » Code

The problem here is that people would have to change that value depending on what version of Solr they're actually using, right? Specifying too high a value would make the config fail for older servers while a lower version number would mean that people with the newest servers would all need to change the setting manually to get the best performance (or new features).

drunken monkey’s picture

Component: Code » solrconfig.xml

Sorry.

cpliakas’s picture

I think we can have different versions of the config for different versions of Solr. Having a 1.4.x, 3.x, 4.x directory think is valid. Are there older versions of 3.x that neither module want to support?

nick_vh’s picture

I would go for 3.5 and not anything below. Traction started around 3.5 (although 3.4 was the first version that was experimented with and should work equally good afaik)

1.4+ and 3.5+ should be the two main ones that we support.

Why 3.5 and not 3.4:

From the changelog (http://www.lucidimagination.com/blog/2011/11/28/lucenesolr-3-5-released/):

Added a very substantial (3-5X) RAM reduction required to hold the
terms index on opening an IndexReader. (LUCENE-2205)

+ some bug fixes, but this ram fix was very significant.
I would certainly not settle for a version lower than 3.4

mollux’s picture

I agree with Nick about 3.5+, the memory fix is really huge

drunken monkey’s picture

Does anyone know which versions the hosted Solr offers provide? If any of those don't have 3.5 yet, that would be bad. (But maybe this is much less of an issue than with PHP? Don't really know.)

I think we can have different versions of the config for different versions of Solr. Having a 1.4.x, 3.x, 4.x directory think is valid. Are there older versions of 3.x that neither module want to support?

We'll definitely do that, but with <luceneMatchVersion> we'd also need different files for 3.0, 3.1, …, and that's not really practical.

So I guess using 3.5 will be fine, but then everyone with a newer server will have to manually correct the setting, right? (It would still work without that, but remove any fixes in the newer versions.)

cpliakas’s picture

Does anyone know which versions the hosted Solr offers provide?

I am in the process of gathering contacts for the other hosted Solr providers to invite them to this conversation. Will probably happen sometime next week.

nick_vh’s picture

Any update?

cpliakas’s picture

I reached out to the other hosted Solr providers, and they pretty much said "great work, we will follow it" or I have received no response from them.

nick_vh’s picture

Status: Active » Needs review

So, let's settle for 3.5. Solr 3.6 will be the latest version of Solr before 4.0 comes out, so we can easily ship with a 3.5 and 3.6 solrconfig, but there are no noticeable improvements that are affecting us in the 3.5 or 3.6 lucene api afaik.

cpliakas’s picture

Status: Needs review » Reviewed & tested by the community

Cool. Based on #1600988-6: Use the <luceneMatchVersion> schema for 3.x Solr versions?, I think we have consensus on both fronts.

cpliakas’s picture

Status: Reviewed & tested by the community » Fixed

Marking as fixed, no commit necessary.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.