Closed (fixed)
Project:
Apache Solr Common Configurations
Component:
solrconfig.xml
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
25 May 2012 at 20:06 UTC
Updated:
3 Jul 2012 at 19:41 UTC
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
Comment #1
pwolanin commentedThis 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.
Comment #2
cpliakas commentedAdding new component flag.
Comment #3
drunken monkeyThe 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).
Comment #4
drunken monkeySorry.
Comment #5
cpliakas commentedI 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?
Comment #6
nick_vhI 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/):
+ some bug fixes, but this ram fix was very significant.
I would certainly not settle for a version lower than 3.4
Comment #7
mollux commentedI agree with Nick about 3.5+, the memory fix is really huge
Comment #8
drunken monkeyDoes 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.)
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.)
Comment #9
cpliakas commentedI 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.
Comment #10
nick_vhAny update?
Comment #11
cpliakas commentedI 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.
Comment #12
nick_vhSo, 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.
Comment #13
cpliakas commentedCool. Based on #1600988-6: Use the <luceneMatchVersion> schema for 3.x Solr versions?, I think we have consensus on both fronts.
Comment #14
cpliakas commentedMarking as fixed, no commit necessary.