Solr Upgrade Notes

• All <lib …​/> directives. This means that Solr Cell (aka Tika), Learning to Rank, Clustering (with Carrot2), language identification, and Velocity (for the /browse sample search interface) are no longer enabled out of the box.
• The /browse, /tvrh, and /update/extract request handlers.
• The Term Vector Component.

• The XSLT and Velocity response writers.

  All of these items can be added to your Solr implementation by manually editing solrconfig.xml to add them back in, or use the Config API.

  The sample_techproducts_configs and the examples found in ./example are unchanged.

Configsets that have been uploaded with an unsecured Configset API (i.e., when authentication is not enabled) are considered "Untrusted Configsets".

In order to bolster Solr’s out-of-the-box security, these untrusted configsets are no longer allowed to use the <lib …​/> directive to implement contribs or custom Jars.

When upgrading to 8.4, if you are using untrusted configsets that contain <lib ../> directives, their corresponding collections will not load (they will cease to work). You have a few options in this case:

• You can secure your Solr instance with authentication and re-upload the configset (using the bin/solr zk upconfig …​ Solr CLI command);
• You can put your custom Jars in Solr’s classpath instead of lib directories;

• You can try the new package management system to manage your custom Jars.

  See the section Upload a Configset for more details about trusted vs. untrusted configsets.

Our default Jetty configuration has been updated to now set a Content-Security-Policy (CSP) by default. See ./server/etc/jetty.xml for details about how it is configured.

As a result of this change, any custom HTML served by Solr’s HTTP server that contains inline Javascript will no longer execute in modern browsers. The options for you are:

• Change your JavaScript code to not run inline any longer;
• Edit jetty.xml to remove CSP (creating weaker security protection);
• Remove/alter the headers with a reverse proxy.

SolrJ now supports the shards.preference parameter for single-shard scenarios to ensure multi-shard and single-shard request routing works in the same way.

See Cloud Request Routing and shards.preference Parameter for details.

QueryResponse.getExplainMap() type has changed from Map<String, String> to Map<String, Object> in order to support structured explanations.

This change is expected to be mostly back-compatible. Compiled third-party components will work the same due to type erasure, but source code changes may be required.

After the addition of CaffeineCache in 8.3, legacy SolrCache implementations are deprecated and likely to be removed in 9.0.

Users are encouraged to transition their cache configurations to use org.apache.solr.search.CaffeineCache as soon as feasible.

Solr has a new cache implementation, CaffeineCache, which is now recommended over other caches. This cache is expected to generally provide most users lower memory footprint, higher hit ratio, and better multi-threaded performance.

Since caching has a direct impact on the performance of your Solr implementation, before switching to any new cache implementation in production, take care to test for your environment and traffic patterns so you fully understand the ramifications of the change.

Routed aliases now use collection properties to identify collections that belong to the alias; prior to 8.2, these aliases used core properties.

This is backward-compatible and aliases created with prior versions will continue to work. However, new collections will no longer add the routedAliasName property to the core.properties file so any external code depending on this location will need to be updated.

The behavior of the maxBooleanClauses parameter has changed to reduce the risk of exponential query expansion when dealing with pathological query strings.

A default upper limit of 1024 clauses is now enforced at the node level. This was the default prior to 7.0, and it can be overridden with a new global parameter in solr.xml. This limit will be enforced for all queries whether explicitly defined by the user (or client), or created by Solr and Lucene internals.

An identical parameter is available in solrconfig.xml for limiting the size of queries explicitly defined by the user (or client), but this per-collection limit will still be restricted by the global limit set in solr.xml.

If your use case demands that you a lot of OR or AND clauses in your queries, upon upgrade to 8.1 you may need to adjust the global maxBooleanClauses parameter since between 7.0 and 8.1 the limit was effectively unbounded.

For more information about the new parameter, see the section Format of solr.xml: maxBooleanClauses.

The default Log4j2 logging mode has been changed from synchronous to asynchronous. This will improve logging throughput and reduce system contention at the cost of a slight chance that some logging messages may be missed in the event of abnormal Solr termination.

If even this slight risk is unacceptable, the Log4j configuration file found in server/resources/log4j2.xml has the synchronous logging configuration in a commented section and can be edited to re-enable synchronous logging.