Major Changes in Solr 10

Solr 10.0 is a major new release of Solr.

This page highlights the most important changes including new features and changes in default behavior as well as previously deprecated features that have now been removed.

Solr 10 Upgrade Planning

Before starting an upgrade to this version of Solr, please take the time to review all information about changes from the version you are currently on up to this one, to include the minor version number changes as well.

There is a new limitation introduced in Solr 9.10, and that which is especially relevant to Solr 10 and beyond. A Solr node will now fail to start if it’s major.minor version (e.g. 9.10) is lower than that of any existing Solr node in a SolrCloud cluster (as reported by info in "live_node"). What this means is that Solr supports rolling upgrades but not rolling downgrades spanning a major version. This compatibility safeguard can be toggled with "SOLR_CLOUD_DOWNGRADE_ENABLED".

System Requirements

Minimum Java version for Solr 10.x is Java 21.

Solr CLI and Scripts

The Solr CLI has gone through some significant renovations to reduce technical debt, and now functions more consistently and predictably. Most notably, CLI commands now use unix-style options, e.g. --help instead of -help. Users are urged to review all use of the bin/solr command, such as in scripts and documentation, to ensure that the correct options are being used.

Some key changes that you may run into are:

  • Commands that interact with Solr now all use --solr-url (or -s) plus a --name (or -c) to specify the Solr to interact with.

  • You may use --zk-host (or -z) in place of the --solr-url option to lookup the Solr host.

  • Basic Authentication support has been added to bin/solr via the --credentials (or -u) option.

  • Some short and single-letter options have been removed to avoid conflicts or in favor to other options.

To learn about the updated options in each CLI tool, use the --help option or look up the tool in the documentation.

Additionally, the bin/solr delete command no longer deletes a configset when you delete a collection. Previously if you deleted a collection, it would also delete it’s associated configset if it was the only user of it. Now you have to explicitly provide a --delete-config option to delete the configsets. This decouples the lifecycle of a configset from that of a collection.

The bin/solr start --bootstrap_conf flag is a legacy feature for converting from Solr to SolrCloud mode and has been removed.

The system property "bootstrap_confdir" (recently renamed to "solr.configset.bootstrap.confdir") used in bin/solr start allwowed a collection creation command to default to the examination of system properties in the absence of proper creation parameters by the same name (like "collection.configName"). That no longer happens in Solr 10. It is only used to load a configuration as a ConfigSet.

SolrJ

  • Starting in 10, the Maven POM for SolrJ does not refer to SolrJ modules like ZooKeeper. If you require such functionality, you need to add additional dependencies.

  • SolrClient implementations that rely on "base URL" strings now only accept "root" URL paths (i.e. URLs that end in "/solr"). Users who previously relied on collection-specific URLs to avoid including the collection name with each request can instead achieve this by specifying a "default collection" using the withDefaultCollection method available on most SolrClient Builders.

  • Minimum Java version for Solrj 10.x is Java 17.

  • Deprecate CloudSolrClient’s ZooKeeper Hosts constructor. Users are encouraged to supply Solr URLs instead of communicating with ZooKeeper. It’s not likely to be removed before Solr 11.

  • Rename BinaryResponseParser and BinaryRequestWriter including StreamingBinaryResponseParser to JavaBinRequestWriter, JavaBinResponseParser, StreamingJavaBinResponseParser. This makes it clear that they pertain specifically to “JavaBin” rather than binary in general.

  • The system property solr.httpclient.builder.factory now only configures SolrClients using a Jetty based HttpClient, not an Apache one.

SolrCloud Overseer

SolrCloud now supports disabling the "Overseer", which is an elected node responsible for processing all cluster administration requests and collection state updates. When disabled, any node that either receives such a request or wishes to do it internally will execute the command. It was possible to disable the Overseer since Solr 9 using undocumented configuration in solr.xml (distributedClusterStateUpdates & distributedCollectionConfigSetExecution) that have since been removed. Now this mode is toggled either with a boolean cluster property overseerEnabled, or an env var SOLR_CLOUD_OVERSEER_ENABLED. In Solr 11, the Overseer might cease to exist, in an effort to simplify SolrCloud and maintenance.

Upgrades: This choice cannot be changed with a rolling upgrade; doing so is highly risky. All nodes in the cluster must always have a consistent understanding of the overseer’s enablement. If using the cluster property toggle, use the bin/solr cluster CLI utility to set it while the cluster is offline. If using the env var; ensure each Solr node is configured to start with the setting set consistently.

When the Overseer is disabled, it is nonetheless still elected, which can be influenced by node roles. If you are using any cluster singleton plugins, they execute on the node elected to be the Overseer.

In general, most users won’t notice a difference. Commands should execute faster without the Overseer. Debugging some SolrCloud problems with the Overseer is more challenging than without since the Overseer is complex (a principal reason for it’s disablement). But the Overseer centralized some processing that results in efficiencies for large clusters in some scenarios. If you have a collection that has many replicas (hundreds), and many are co-located on the same node, then node stops and starts will internally interact with ZooKeeper more. Using minStateByteLenForCompression will help. Creating a replica (either via collection creation or other circumstances) can take more time without the Overseer if these creation commands are delivered to many nodes around the cluster. That can be avoided simply by sending admin requests to a consistent node.

Service installer

The service installer now installs a systemd startup script instead of an init.d startup script. It is up to the user to uninstall any existing init.d script when upgrading.

SolrCloud request routing

HTTP requests to SolrCloud that are for a specific core must be delivered to the node with that core, or else an HTTP 404 Not Found response will occur. Previously, SolrCloud would try too hard scanning the cluster’s state to look for it and internally route/proxy it. If only one node is exposed to a client, and if the client uses the bin/solr export tool, it probably won’t work.

Modern NLP Models from Apache OpenNLP with Solr

Solr now lets you access models encoded in ONNX format, commonly sourced from HuggingFace. The DocumentCategorizerUpdateProcessorFactorythat lets you perform sentiment and other classification tasks on fields. It is available as part of the analysis-extras module.

Deprecation removals

  • The jaegertracer-configurator module, which was deprecated in 9.2, is removed. Users should migrate to the opentelemetry module.

  • OpenTracing libraries were removed and replaced with OpenTelemetry libraries. Any Java agents providing OpenTracing tracers will no longer work. Telemetry tags http.status_code and http.method have been deprecated, newer version of the tags have been added to the span data: http.response.status_code, http.request.method.

  • The analytics module, which was deprecated in 9.2, is removed.

  • The sysProp -Dsolr.redaction.system.pattern, which allows users to provide a pattern to match sysProps that should be redacted for sensitive information, has been removed. Please use -Dsolr.hiddenSysProps or the envVar SOLR_HIDDEN_SYS_PROPS instead.

  • The <hiddenSysProps> solr.xml element under <metrics> has been removed. Instead use the <hiddenSysProps> tag under <solr>, which accepts a comma-separated string. Please see -Dsolr.redaction.system.pattern, which allows users to provide a pattern to match sysProps that should be redacted for sensitive information, has been removed. Please use -Dsolr.hiddenSysProps or the envVar SOLR_HIDDEN_SYS_PROPS instead.

  • The node configuration file /solr.xml can no longer be loaded from Zookeeper. Solr startup will fail if it is present.

  • The legacy Circuit Breaker named CircuitBreakerManager, is removed. Please use individual Circuit Breaker plugins instead.

  • BlobRepository and BlobHandler have both been removed in favour of the FileStore API implementation (per node stored file). To share resource intensive objects across multiple cores in components you should now use the CoreContainer.getObjectCache approach

  • The language specific Response Writers, which were deprecated in 9.8 in favour of more widely used formats like JSON have been removed. The removed writer types (invoked as part of the wt parameter) include python, ruby, php, and phps.

  • The XLSX Response Writer (wt=xlsx), which was deprecated in 9.10, has been removed. Users needing Excel export functionality should use CSV format (wt=csv) and convert it to Excel format using external tools or libraries.

  • The deprecated support for configuring replication using master/slave terminology is removed. Use leader/follower.

  • Support for the <lib/> directive, which historically could be used in solrconfig.xml to add JARs on a core-by-core basis, was deprecated in 9.8 and has now been removed. Users that need to vary JAR accessibility on a per-core basis can use Solr’s Package Manager. Users who that don’t need to vary JAR access on a per-core basis have several options, including the <sharedLib/> tag supported by solr.xml or manipulation of Solr’s classpath prior to JVM startup.

  • Kerberos based authentication has been removed. This results in changes to SolrJ, the Solr Admin app, and the removal of the hadoop-auth module.

  • Storing indexes and snapshots in HDFS has been removed. This results in changes to solrconfig.xml and related configuration files and removal of the hdfs module.

  • ExternalFileField field type has been removed.

  • CurrencyField has been removed. Users should migrate to the CurrencyFieldType implementation.

  • The addHttpRequestToContext option in solrconfig.xml has been removed; it’s obsolete. Nowadays, the HTTP request is available via internal APIs: SolrQueryRequest.getHttpSolrCall().getReq().

  • EnumField has been removed. Users should migrate to the EnumFieldType implementation.

  • PreAnalyzedField and PreAnalyzedUpdateProcessor have been removed due to incompatibility with Lucene 10 (SOLR-17839).

  • The ConcurrentMergeScheduler’s autoIOThrottle default changed to false but true may be configured to retain prior behaviour. (SOLR-17631).

  • The TieredMergePolicy’s segmentsPerTier default changed to 8 but 10 may be configured to retain prior behaviour. (SOLR-17917).

  • BlobHandler and the .system collection have been removed in favour of FileStore API. (SOLR-17851).

  • The deprecated transient Solr cores capability has been removed. (SOLR-17932)

Security

  • There is no longer a distinction between trusted and untrusted configSets; all configSets are now considered trusted. To ensure security, Solr should be properly protected using authentication and authorization mechanisms, allowing only authorized users with administrative privileges to publish them.

Upgrade to Jetty 12.x

Solr upgraded to Jetty 12.x from 10.x as Jetty 10 and 11 have reached end-of-life support. Jetty 12.x requires Java 17 or newer and is fully compatible with Solr’s new minimum requirement of Java 21. This upgrade brings support for modern HTTP protocols and adopts the Jakarta EE 10 namespace. For more details, see https://webtide.com/jetty-12-has-arrived/.

Open Telemetry

  • The Prometheus exporter, JMX, SLF4J and Graphite metric reporters have been removed. Users should migrate to using OTLP or the /admin/metrics endpoint with external tools to get metrics to their preferred backend such as the OTEL Collector.

  • Core renaming and swapping will reset the state of all the corresponding cores metrics

Docker

The OS version of the official Docker image and provided Dockerfile has been upgraded to Ubuntu 24 (noble) from Ubuntu 22 (jammy).

Analysis and Tokenizers

PathHierarchyTokenizer Behavior Change

Due to Lucene 10 changes (https://github.com/apache/lucene/pull/12875), PathHierarchyTokenizer now produces sequential tokens (position increment = 1) instead of overlapping tokens (position increment = 0). This affects ancestor queries that relied on overlapping token matching. Users should test existing queries and update configurations if needed.

  • In Lucene 10, the OrdinalIterator class has been moved from the main lucene-facet module to the lucene-sandbox module. This requires Solr core to now include a dependency on lucene-sandbox to support faceting operations that use this class.

Example configuration change:

<!-- Before: Query-time tokenization for ancestors -->
<fieldType name="ancestor_path" class="solr.TextField">
  <analyzer type="index">
    <tokenizer class="solr.KeywordTokenizerFactory"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.PathHierarchyTokenizerFactory" delimiter="/"/>
  </analyzer>
</fieldType>

<!-- After: Index-time tokenization for modern behavior -->
<fieldType name="ancestor_path" class="solr.TextField">
  <analyzer type="index">
    <tokenizer class="solr.PathHierarchyTokenizerFactory" delimiter="/"/>
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.PathHierarchyTokenizerFactory" delimiter="/"/>
  </analyzer>
</fieldType>