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 be sure 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. For example, if you are currently using Solr 9.1, you should review changes made in all subsequent 9.x releases in addition to the 10.0-specific changes on this page.

Users planning their upgrade process should be aware of a change introduced in Solr 9.10 which is especially relevant to Solr 10 and beyond. By default, starting in 9.10 SolrCloud nodes will now fail to start if their major.minor version (e.g. 9.10) is lower than the highest version found elsewhere in the SolrCloud cluster. The intention of this change is to allow Solr to support rolling upgrades but not rolling downgrades spanning a major version. This compatibility safeguard can be disabled via the environment variable SOLR_CLOUD_DOWNGRADE_ENABLED.

System Requirements

Solr 10.0 requires at least Java 21, while SolrJ 10.0 requires at least Java 17.

Solr 10.1

Misc

For SSL (https), it’s no longer necessary to set the "urlScheme" cluster property since the SOLR_SSL_ENABLED env var (or solr.ssl.enabled sys-prop) suffices. These are now honored by CloudSolrClient, as well as scheme detection from the connection string / hosts. The "urlScheme" cluster property and httpShardHandlerFactory configuration is likely to be deprecated; feedback welcome.

If you use SortingMergePolicyFactory for index sorting and your schema declares _root_, Solr configures a new mechanism in Lucene that affects the index to support nested/block documents with sorted indexes. This requires a fresh Solr 10.1 index. To retain compatibility with existing sorted indexes, deferring a reindex, keep luceneMatchVersion at 10.3.1 or earlier in solrconfig.xml.

Universal connection string support

Introduced a universal Solr connection string for SolrCloud connections.

Connections can now be configured via HTTP(S) without exposing ZooKeeper details, while the legacy ZooKeeper-based connection method remains fully supported.

Examples: solrConnection=http://solr1:8983/solr,http://solr2:8983/solr solrConnection=zoo1:2181,zoo2:2181,zoo3:2181/solr

The universal connection string is now supported in the following components and entry points:

  • Added CloudSolrClient.Builder(String) constructor in SolrJ for configuring SolrCloud clients using either HTTP(S)-based or ZooKeeper-based connection strings.

  • Added solrConnection parameter to all streaming functions in the SolrJ Streaming module. The existing zkHost parameter remains supported.

  • Added withDefaultSolrConnection and withCollectionSolrConnection methods to StreamFactory in the SolrJ Streaming module.

  • Solr SQL JDBC driver now supports both HTTP-based (jdbc:solr:http://solr1.example.com:8983/solr?collection=COLLECTION_NAME) and ZooKeeper-based (jdbc:solr://zoo.example.com:2181/solr?collection=COLLECTION_NAME) JDBC URLs.

  • Added --solr-connection option to the CLI tools.

  • Updated Solr CLI -s short option to invoke --solr-connection instead of --solr-url, which is a backwards compatible change.

  • Added solrConnection parameter to the Join Query Parser.

Connecting to Other Clusters

Streaming expressions and the cross-collection join query parser now restrict which SolrCloud clusters a zkHost or solrConnection parameter may refer to:

  • A ZooKeeper connection string must match the local cluster’s exactly (including any chroot), or be listed in the new allowZkHosts setting in solr.xml (or the solr.security.allow.zk.hosts system property).

  • An HTTP(S) connection string must refer to live nodes of the local cluster, or to hosts listed in allowUrls.

  • The cross-collection join query parser no longer accepts both zkHost and solrUrl; specify at most one.

If you use these features to query another cluster, add its connection details to the corresponding setting before upgrading.

v2 API

Starting in Solr 10.1 it is no longer possible for users to disable the v2 API by use of the solr.api.v2.enabled system property, and the Solr server and tooling (bin/solr, Admin UI, etc.) will start using these APIs internally.

Former users of solr.api.v2.enabled looking to upgrade to Solr 10.1 or newer should take care to review any custom RuleBasedAuthorizationPlugin permissions and ensure that v2 API paths are adequately secured.

Users who deploy a proxy in front of Solr should also review this setup to ensure that it allows access to the v2 API root path, /api.

JWT Authentication

The blockUnknown setting in the JWT Authentication plugin now defaults to true, meaning requests without a valid JWT token are blocked by default. In Solr 10.0, the code default was false (pass-through), which contradicted the reference guide documentation that described true as the default. Users upgrading from 10.0 who relied on the pass-through behavior must explicitly set "blockUnknown": false in their security.json.

Security

PKI Authentication v1 support has been removed. Solr 10.1 nodes only send and accept the SolrAuthV2 (v2) header for inter-node communication.

Before performing a rolling upgrade to 10.1, ensure no node in the cluster has solr.pki.sendVersion=v1 set, as those nodes would send the legacy SolrAuth header that 10.1 nodes will reject. The solr.pki.sendVersion and solr.pki.acceptVersions system properties are no longer recognized in 10.1 and can be removed from your configuration.

The Basic Authentication password policy has been strengthened: a password may no longer be equal to its username. Login attempts where the password equals the username are now rejected, and creating or editing such a user (via the Admin UI, the Authentication API, or bin/solr auth) is no longer allowed.

If you are upgrading and still have Basic Auth users whose password equals their username, you can temporarily re-enable the old behavior by setting the system property -Dsolr.security.auth.basicauth.allowuseraspassword=true (or the environment variable SOLR_SECURITY_AUTH_BASICAUTH_ALLOWUSERASPASSWORD=true). When enabled, this escape hatch relaxes both the login-time check and the user creation/editing check, so existing accounts keep working and can still be managed. It is intended as a temporary measure while you migrate the affected accounts to stronger passwords, and should be removed once that is done.

SolrJ

The HttpJdkSolrClient and HttpJettySolrClient no longer have default thread/executor limits. Nonetheless the Executor is configurable.

HttpSolrClient returns; this time as a base class for HttpJettySolrClient and HttpJdkSolrClient. Its builder will dynamically detect if solr-jetty is available and use that, otherwise it will use the JDK client.

CommonParams.QT has been un-deprecated. Nonetheless, if your code makes explicit reference to "qt" when constructing a standard request, there is usually a better way.

Solr 10.0

Solr Jetty parameters

The previous SOLR_JETTY_HOST environment variable and -Dsolr.jetty.host System Property are deprecated and will be removed in a future release. Please update your configuration to use SOLR_HOST_BIND and -Dsolr.host.bind instead.

The previous SOLR_HOST and host are deprecated and now use SOLR_HOST_ADVERTISE and solr.host.advertise.

The previous jetty.port is deprecated and now use solr.port.listen.

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, "long-options" now use double-dashes per Unix style conventions, e.g. --help instead of -help. Users are urged to review all use of the bin/solr command in their automation, scripts, and documentation to ensure that the correct options are being used.

Some key changes that users may encounter 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.

  • -z/--zk-host is now supported across all bin/solr tools as an alternative to -s/--solr-url.

  • bin/solr now allows users to specific basic auth credentials via the -u/--credentials option, supplementing the previous SOLR_AUTHENTICATION_OPTS-based support.

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

  • bin/solr start now defaults to starting Solr in SolrCloud mode. Use the --user-managed switch to start in standalone (user-managed) mode instead.

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 its 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.

Several scripts formerly provided with Solr have been removed, including bin/post, bin/postlogs, and zkcli.sh. Users should instead rely on bin/solr post and bin/solr zk as appropriate.

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.

  • Classes using Jetty HttpClient have been moved to a new package org.apache.solr.solrj.jetty. To use them from your application, you need to include the new solr-solrj-jetty artifact. The following classes were renamed with some refactorings: Http2SolrClient to HttpJettySolrClient, ConcurrentUpdateHttp2SolrClient to ConcurrentUpdateJettySolrClient, LBHttp2SolrClient to LBJettySolrClient. CloudHttp2SolrClient.Builder has moved to CloudSolrClient; users should generally have no need to refer to CloudHttp2SolrClient or any class/member with "http2" in it. The builder will check if Jetty HttpClient is available and use that, otherwise fallback on a JDK based HttpClient. CloudJettySolrClient is new, providing an explicit option. The system property solr.solrj.http.jetty.customizer (formerly solr.httpclient.builder.factory) can configure a HttpJettySolrClient. The only built-in implementation is org.apache.solr.client.solrj.jetty.PreemptiveBasicAuthClientCustomizer, renamed from PreemptiveBasicAuthClientCustomizer.

  • 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 deprecated SolrClient implementations based on Apache HttpClient are removed from SolrJ, thus the related dependencies are no longer present.

  • The SolrQuery class has moved from org.apache.solr.client.solrj.SolrQuery to org.apache.solr.client.solrj.request.SolrQuery. Update your imports accordingly.

  • A number of other classes moved to different packages to be better organized, including: ShardTerms, DelegatingClusterStateProvider, JavaBinRequestWriter, RoutedAliasTypes, XMLRequestWriter, JacksonContentWriter, FastStreamingDocsCallback, InputStreamResponse, InputStreamResponseParser, JavaBinResponseParser, ResponseParser, StreamingJavaBinResponseParser, StreamingResponseCallback, XMLResponseParser, JacksonDataBindResponseParser, JsonMapResponseParser, SocketProxy

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 its 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 Hugging Face. The DocumentCategorizerUpdateProcessorFactory lets you perform sentiment and other classification tasks on fields. It is available as part of the analysis-extras module.

New Experimental Admin UI

A new experimental Admin UI is available alongside the existing Admin UI (SOLR-14414). It can be accessed at the URL path /solr/ui/. This UI is still in active development and provided as a preview; the existing Admin UI remains the default.

Enhancements

  • The efSearchScaleFactor parameter is now available for the KNN query parser (SOLR-17928). This parameter controls how many candidate vectors are explored during HNSW graph traversal, allowing users to independently tune search accuracy versus the number of results returned. Previously, improving accuracy required increasing topK (which returns more results), but efSearchScaleFactor enables exploring more candidates while still receiving exactly topK results. The efSearch value is calculated internally as efSearchScaleFactor * topK. Default value is 1.0, which means efSearch defaults to topK.

  • Scalar and binary quantized dense vectors are now supported for DenseVectorField (SOLR-17780, SOLR-17812). Quantization reduces memory consumption and can improve search performance at some cost to accuracy. See the reference guide for configuration details.

  • GPU-accelerated approximate nearest neighbor search is now available via the cuVS-Lucene pluggable codec (SOLR-17892). This allows NVIDIA GPU hardware to be used for vector search workloads.

  • Early termination strategy for KNN queries is now supported (SOLR-17814). PatienceKnnVectorQuery is a version of knn vector query that exits early the graph when HNSW queue saturates over a saturationThreshold for more than patience times.

  • Lexically accelerated vector search is now supported (SOLR-17813). SeededKnnVectorQuery is a version of knn vector query that introduces a “seed” query, allowing the search to start from a predefined subset of documents and guide the vector similarity computation.

  • The filteredSearchThreshold parameter is now available to regulate ACORN-based filtering in vector search (SOLR-17815). This approach addresses the performance limitations typically associated with pre-filtering and post-filtering strategies by modifying both the construction and search phases of the HNSW graph.

  • Fixed incorrect behavior of TextToVectorUpdateProcessor during partial updates (SOLR-17843).

Renaming of HNSW Parameters

Attention:

  • The llm module has been renamed to language-models.

  • The HNSW parameters hnswMaxConnections and hnswBeamWidth have been renamed to hnswM and hnswEfConstruction, respectively, so they must be updated accordingly in the schema.xml file.

Deprecation Code Removals

  • Several deprecated modules have been removed.

    • jaegertracer-configurator is gone; the new opentelemetry module should be used instead.

    • analytics has been removed

    • hadoop-auth (including the solr.KerberosPlugin class) has been removed

  • 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 removed from the span data; use http.response.status_code and http.request.method instead. (SOLR-18110)

  • 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.

  • 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, BlobHandler, and the .system collection have all been removed in favour of the FileStore API implementation (SOLR-17851). 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 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.

  • 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).

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

  • TikaLanguageIdentifierUpdateProcessor, which was deprecated in 9.10, has been removed. Users should use LangDetectLanguageIdentifierUpdateProcessor or OpenNLPLangDetectUpdateProcessor instead for language detection. (SOLR-17960)

  • LocalTikaExtractionBackend, which was deprecated in 9.10, has been removed. The tikaserver extraction backend is now the only supported backend for the ExtractingRequestHandler, and the default. Users must configure a Tika Server URL via the tikaserver.url parameter. (SOLR-17961). Also, the ability to configure Tika parse context with parseContext.config is no longer supported. Tika parser-specific properties must now be configured directly on the Tika Server itself, rather than through Solr configuration. Please refer to the Tika Server documentation for details on how to set these properties.

  • The Prometheus exporter, JMX, SLF4J and Graphite metric reporters have been removed. Prometheus metrics (node-scoped) are now available natively via the /admin/metrics endpoint on each solr node (see OpenTelemetry section below). Users can also push metrics via OTLP to any OTLP-supported backend such as the OTEL Collector.

  • The deprecated JaspellLookupFactory suggester implementation has been removed. The default suggester lookup implementation is now FSTLookupFactory, which provides better memory efficiency.

  • SolrInfoMBeanHandler and PluginInfoHandler have been removed

  • The deprecated ManagedSynonymFilterFactory has been removed. Use ManagedSynonymGraphFilterFactory instead with FlattenGraphFilterFactory at index time.

  • The deprecated LowerCaseTokenizer and LowerCaseTokenizerFactory have been removed. These classes were deprecated in Solr 8 and can be replaced by combining LetterTokenizerFactory with LowerCaseFilterFactory.

  • The deprecated solrcore.properties configuration method has been removed. The ability to configure a core via a custom properties file using the core.properties "property" setting remains.

  • The deprecated VMParamsAllAndReadonlyDigestZkACLProvider class has been removed. Use a combination of DigestZkACLProvider and VMParamsZkCredentialsInjector instead. (SOLR-18122)

  • The legacy V1 ADDROLE and REMOVEROLE commands (and their SolrJ client and experimental V2 counterparts) are deprecated as of 10.1 and scheduled for removal in Solr 11. Users must switch to "node roles" (system properties) (e.g., -Dsolr.node.roles=data:on,overseer:preferred) at startup. The roles field in CLUSTERSTATUS is also deprecated.

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.

  • stream.file, stream.url, and stream.body params are no longer supported.

  • /update/extract (ExtractingRequestHandler in the extraction module) requires the update permission rather than read, since it indexes documents. Deployments where read-only users submit documents through /update/extract must grant those users update as well.

Upgrade to Jetty 12.x and Jakarta namespace

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/. This migration marks the point at which Solr no longer includes any JAR with "javax" in it — the Jakarta migration is complete.

OpenTelemetry

Solr 10 has migrated from Dropwizard metrics to OpenTelemetry (OTEL) for observability. This migration provides native Prometheus support, OTLP support, exemplar support for tracing correlation, and native attributes and labels on all metrics.

  • All metrics have been migrated to snake-case metric names instead of dot-delimited format and now natively include attributes/labels.

  • The /admin/metrics API now defaults to Prometheus exposition format and no longer supports XML/JSON/javabin. You can specify wt=prometheus as a parameter for Prometheus format or wt=openmetrics for OpenMetrics exposition format with exemplars support (distributed tracing must be enabled to view exemplars).

  • The metrics API supports filtering by metric name and attributes. See Metrics API Filter for more info.

  • OTLP metrics exporter via gRPC or HTTP is now supported with the OpenTelemetry module. Users can enable the module to push metrics to their preferred OTLP-supported backend.

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

Solr 10 introduced significant changes to metrics, including new metric names and API endpoints. These metrics are currently considered Beta and may change in minor releases without notice.

Docker

The OS version of the official Docker image and provided Dockerfile has been upgraded to Ubuntu 24 (noble) from Ubuntu 22 (jammy). The Docker base image is eclipse-temurin:25-jre-noble.

Miscellaneous

Solr logs no longer include webapp=/solr and there’s no longer a webapp key-value pair in the internal context.

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.

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>

Learning To Rank (LTR)

A new feature vector cache was added that is used not only for feature logging but also for the reranking phase (SOLR-16667).

Solr 10.1

OpenTelemetry

The new OTEL based metric system introduced in 10.0 is considered BETA, and some breaking changes are to be expected in this and coming minor releases.

OTLP protocols

The opentelemetry module no longer includes some dependencies, dropping gRPC support out-of-the-box. The default export protocol for tracing has changed from grpc to http/protobuf (OTLP port 4318 instead of 4317). The default for the separate OTLP metrics exporter’s solr.metrics.otlpExporterProtocol has likewise changed from grpc to http.

Use of gRPC can be restored by adding the required gRPC & Netty jars to the opentelemetry module’s lib directory, and setting OTEL_EXPORTER_OTLP_PROTOCOL=grpc (tracing) and/or solr.metrics.otlpExporterProtocol=grpc (metrics) as needed.

OTLP Metric Names Changed to Dot-Separated Format

Breaking change for OTLP consumers.

Solr’s metric names exported via OTLP now follow the OpenTelemetry semantic convention of using dot-separated names instead of the underscore-separated names used in Solr 10.0.

For example, solr_core_requests is now solr.core.requests, and solr_node_executor is now solr.node.executor.

Prometheus output is unaffected. The OTel Prometheus exporter automatically converts dots to underscores, so the /admin/metrics?wt=prometheus endpoint continues to produce the same metric names as before (e.g., solr_core_requests_total).

Workaround for OTLP consumers depending on the old names: Users who consume Solr metrics via OTLP and rely on the 10.0 underscore-format names can use metric renaming or transformation features in their OpenTelemetry Collector pipeline to convert the new dot-separated names back to the old format during the transition.

Metric that are Removed or Changed

  • The metric solr_core_indexsearcher_open_warmup_time has been removed as it duplicated solr_core_indexsearcher_warmup_time

  • The metric solr.zk.cumulative.children_fetched has been removed

  • The metric solr.zk.child.fetches is now solr.zk.get_children.ops

  • All CrossDC consumer metrics have been renamed: crossdc.consumer. → solr.crossdc.consumer. (e.g., crossdc.consumer.output.total → solr.crossdc.consumer.output.total)

  • All CrossDC producer metrics have been renamed: solr.core.crossdc.producer. → solr.crossdc.producer. (e.g., solr.core.crossdc.producer.submitted → solr.crossdc.producer.submitted)

  • The Prometheus JVM CPU utilization metrics lost their _ratio suffix, as the updated OpenTelemetry exporter no longer maps the OTel unit 1 to a _ratio suffix: jvm_system_cpu_utilization_ratio → jvm_system_cpu_utilization and jvm_cpu_recent_utilization_ratio → jvm_cpu_recent_utilization.

Update your dashboards or other metrics consumers accordingly.

Overseer Status Metrics Removed

The OVERSEERSTATUS Collection API response no longer includes per-operation timing metrics but per-operation requests and errors counts still exist. Users needing per-operation latency can use distributed tracing as a substitute via OpenTelemetry.

Lucene Codec Change

Solr 10.1 upgrades the underlying Lucene library from 10.3 to 10.4, which introduces a new index codec (Lucene104). New index segments will be written using the Lucene104 codec format. Older segments will continue to be readable.

After upgrading to Solr 10.1, downgrading to an earlier Solr 10.0.x version may fail because the older version does not include the Lucene104 codec needed to read the newly written segments. If you require the ability to roll back, back up your indexes before upgrading.

API Changes

Solr 10.1 changes the V1 API signature in the ConfigSets API for uploading a single file Previously the default for over write is false when using the v1 API, but true when using the v2 API. Overwrite makes sense when uploading a complete configset and you want to eliminate any remnants configset files from the previous one when you replaced it with a new one. However for a single file upload it has no bearing and only existed due to a bad V1 API design choice.

Docker

The gosu binary is no longer installed in the Solr Docker image. See gosu github page for alternatives, such as runuser, setpriv or chroot.

Max distributed requests now configurable

The internal HTTP client used for distributed shard sub-requests previously had a hard-coded limit of 1000 concurrent async requests per node. In large clusters, a single query can fan out to hundreds of sub-requests, quickly exhausting this limit and causing requests to queue, potentially leading to stalls or timeouts. This limit is now configurable via the system property solr.solrj.http.jetty.async_requests.max.

Current permit utilization can be monitored via the solr_client_request_async_permits metric (see HTTP Client Registry).

Language Detection

The langid module’s LangDetectLanguageIdentifierUpdateProcessor now uses io.github.azagniotov:language-detection instead of the abandoned com.cybozu.labs:langdetect (last released in 2012). The new library supports a broader set of languages and uses a different statistical model, so detection results may differ from previous versions — particularly for short texts, texts that mix Latin characters with other scripts, or documents containing CJK characters alongside Latin-script content.

Query Changes

  • Combined Query Feature is now available, enabling the execution of multiple queries of multiple kinds across multiple shards (SOLR-17319). Introduced CombinedQuerySearchHandler for hybrid search, using reciprocal rank fusion (RRF) by default and supporting custom ranking algorithms via plugins.