lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: any easy way to find out when a core's index physical file has been last updated?
Date Fri, 04 Sep 2015 18:15:50 GMT
On 9/4/2015 10:14 AM, Renee Sun wrote:
> I will start use autocommit with confidence it will greatly help reducing
> the false commit requests (a lot) from processes in our system.
> Regarding the solr version, it is actually a big problem we have to resolve
> sooner or later.
> When we upgraded to Solr 3.5 about 2 years ago, to avoid re-index our large
> data, we used :
> <luceneMatchVersion>LUCENE_29</luceneMatchVersion>
> which seems to work fine except a lot of such warnings in catalina.out:
> WARNING: StopFilterFactory is using deprecated LUCENE_29 emulation. You
> should at some point declare and reindex to at least 3.0, because 2.x
> emulation is deprecated and will be removed in 4.0

Setting luceneMatchVersion to an older version, contrary to most
people's expectations, does NOT change the index format.  It basically
turns on a compatibility mode for analysis components like
StopFilterFactory so that the created terms work like the older version,
if the code has a check for that older version that produces different
behavior.  Basically you use LMV to disable analysis bugfixes that don't
work for you.  In your case, any index segments created since your
upgrade are Lucene 3.5 format, not Lucene 2.9.

> We have a built a infrastructure which scales well using solr, is it a good
> practice to upgrade to solr 4.x without using solrCloud if it is possible at
> all?

Almost all of my Solr servers (running 4.x, we have not yet upgraded to
5.x) are NOT running in cloud mode.  Although it would make some aspects
of maintaining my index easier, I would lose some of the functionality
if I upgraded to a fully replicated SolrCloud setup.


View raw message