The SearchStax Managed Search service lets developers set up and deploy Solr infrastructure for Sitecore in minutes and removes the pain of managing and supporting Solr deployments. Hundreds of Sitecore customers are currently using Managed Search to efficiently and effectively manage their Solr infrastructure.

See the Sitecore/Solr Compatibility page for more information on recommendations for the combinations of Sitecore and Solr.

The post Can SearchStax Managed Search provide Solr indexing support for Sitecore? appeared first on SearchStax Docs.

• Apache recently announced that Solr 8.x has reached its end-of-life.
• Solr 9 is not known to be compatible with Sitecore.

What action should operators of Sitecore/Solr/SearchStax systems take in the face of this uncertainly?

At present (December 2024), Sitecore suggests remaining with compatible versions of Solr 8.x. For Sitecore 10.3 and 10.4, that means Solr 8.11.2. Solr versions 8.11.3 and 8.11.4 are thought to be compatible but are not certified.

See Sitecore’s compatibility page for the latest updates on this situation.

Questions?

The post Solr 8.x End-of-Life and Sitecore appeared first on SearchStax Docs.

Sitecore offers a page of advice about optimizing search and indexing of your xDB index.

https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0671173

The post Optimizing the xConnect Search Service appeared first on SearchStax Docs.

A Solr /select query has an optional &rows parameter that tells the Solr responseHandler how many documents to include in the response. The default value is 10 documents. For a given query, response time goes up with the number of rows requested.

For instance, we ran a single-keyword query against a collection of 13,500,000 retail products. The QTime varied with &rows, even though the numFound (number of matches) did not. (QTime is milliseconds that Solr spent processing the query.)

Many factors influence these timings (such as caching), but you can see that minimizing the &rows setting is likely to be a Best Practice.

Sitecore &rows Settings

By default, Sitecore sends /select and /suggest queries to Solr with the &rows parameter set to 1000000, and in some cases, to 100000000. These settings places enormous stress on Solr, sometimes maximizing CPU and JVM usage, because Solr allocates enough memory to hold a million documents before processing each query. Since Sitecore can issue hundreds of these queries in a few seconds, the memory load can exceed Solr’s ability to cope.

SearchStax recommends lowering the default setting:

1. In your Sitecore installation, navigate to App_Config\Sitecore\ContentSearch\Sitecore.ContentSearch.config.
2. Locate <setting name="ContentSearch.SearchMaxResults" value="1000000" />.
3. Change the value to “1000” unless you really do need more than a thousand documents.
4. Save the file and restart Sitecore.

You should see the change reflected in the /select requests recorded in your Load Balancer log files.

For further information, consult this Sitecore Knowledge Base article: https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0671173.

The post Lowering &rows=1000000 appeared first on SearchStax Docs.

Sitecore’s SwitchOnRebuild feature comes in two flavors that mirror the distinction between SWAP and CREATEALIAS. These passages are from Switch SolrCloud Indexes in the Sitecore documentation. Note the distinction between SwitchOnRebuildSolrSearchIndex (for Solr) and SwitchOnRebuildSolrCloudSearchIndex (for SolrCloud):

You use the SwitchOnRebuildSolrSearchIndex class to rebuild and switch Solr indexes. This implementation uses the Solr SWAP command to swap the active and the rebuild indexes.

The mechanism for maintaining and switching two indexes is different when use SolrCloud. The implementation in the SwitchOnRebuildSolrCloudSearchIndex class uses collection aliases: it uses the active alias for search and update operations and the rebuild alias for rebuild operations. When a rebuild operation finishes, the CREATEALIAS command swaps the collections the aliases reference.

So the answer is, “Yes, you can do it.” Just be sure to use the SolrCloud version with Managed Solr.

The post Can we use SwitchOnRebuild with SearchStax? appeared first on SearchStax Docs.

This occurs because of an inconsistency in Sitecore related to the “_indexname” Solr field. This field is stored on Solr using the “string” field type while it should be stored as “keyword”. Please note that this is fixed for Sitecore 10.1 or later.

This causes an error when Sitecore identifies a delete or unpublish operation and tries to inform Solr that this item should be removed from the index. As you can note in the below images, Sitecore always stores the index name as lowercased, but for some reason it uses the original value with capital letters when performing the delete call on Solr.

SearchStax has created a workaround which is already part of the 1.4 release of the SearchStax Managed Search Connector for Sitecore, so if you use this or a newer version you should not have this problem. If you are using an older version, the best solution is to upgrade the package to a newer version.

If that’s not possible, please contact SearchStax support team. They will create a new SearchStax index core which hasn’t any capital letters on its name. This guarantees that any delete operation from a Sitecore index works even if using Sitecore 10.0 or lower version.

The post Unpublish/Delete Fails to Remove Item from Sitecore Index appeared first on SearchStax Docs.

Note that SearchStax supplies explicit instructions for bridging this gap, including the SearchStax Managed Search Connector for Sitecore that performs the configuration for you.

Sitecore can’t connect to Solr:

• IP Filtering. First, be sure that the computer running Sitecore has been whitelisted in the IP filters of the Solr deployment. Note that DHCP can change a server’s IP address without warning. If the connection used to work but then stopped working, suspect this source.
  
  
• Incorrect Sitecore connection string. To connect Sitecore to a Solr cloud cluster, check the SitecoreWebSite/App_Config/ConnectionStrings.config file for an entry similar to:
  
  <add name="solr.search" connectionString="<Solr HTTP Endpoint>/solr;solrCloud=true" />
  
  Solr is unforgiving about this string. An extra / at the end will break it. (In that case, you may see an error mentioning Test connection has failed with an exception. Type: 'SolrConnectionException'.)
  
  The connectionString ends with /solr;solrCloud=true. There is no / between /solr and the semicolon. Sitecore inserts that character automatically.
  
  If you connect to Solr from a browser, which is a good debugging aid, you must include the / prior to the semicolon, as in /solr/;solrCloud=true.
  
  The solrCloud=true parameter is highly recommended for single-node Solr deployments, and is required for Solr clusters.
  
  
• Incorrect xConnect connection string. When using xConnect to index Sitecore xDB databases, for every instance of the xConnect Collection Search role, open the <role-root>/App_Config/ConnectionStrings.config file and set:
  
  <add name="solrCore" connectionString="<Solr HTTP Endpoint>/solr/xdb;solrcloud=true" />
  
  The connectionString ends with /solr/xdb;solrCloud=true. There is no / between /solr/xdb and the semicolon.
  
  
• Sitecore mentions 10.x.x.x:8983. You tried to build an index from the Sitecore Index Manager. The system seemed to hang or took a very long time to complete indexing. There was an error saying “Unable to connect to Solr” and mentioning an internal IP address (10.x.x.x) and port 8983. Alternately, you may have seen a Sitecore message saying “ERROR GetSummary has failed due to an exception.”
  
  This is a known bug in Sitecore. To get around it:
  • Generate the index from the Sitecore Content Editor instead of the Index Manager.
  • Contact Sitecore for a patch file. This bug is being tracked by Sitecore under the reference number – 355209.

  This situation sometimes arises due to a misconfiguration of the Sitecore 10/Solr connection. See Walkthrough: Setting up SolrCloud, section Configure Sitecore to use SolrCloud, step 3:
  
  

  If you only access nodes of SolrCloud within a private network, set the ContentSearch.IndexingManager.DisplayShortStatistic setting to true. This eliminates direct requests to the nodes used to display additional index statistics in the Indexing Manager Wizard.
  
  

• Solr Basic Auth password contains special characters: The Sitecore connection string to Solr often contains the Solr Basic Auth username and password:
  
  https://username:pass%word@<Solr Endpoint>;solrCloud=true
  
  There are special characters that cannot be passed in an HTTP URL. If the password contains % signs, for instance, you will get an error saying “Not a valid Solr URL.” Substitute %25 for % in the URL string, so the above password becomes “pass%25word”.
  
  Or, just use a password without special characters.

Solr.log file contains schema or field errors:

• See our Help Center page on What causes Indexing Errors? for more information.

Questions?

Do not hesitate to contact the SearchStax Support Desk.

The post Sitecore Solr Cloud Connection Errors appeared first on SearchStax Docs.

SearchStax Managed Search service Solr queries may be submitted using either the GET or POST HTTP method. The query string of a GET request is included as part of the URL in the request header. In a POST request, the query string is part of the data payload and does not inflate the header size.

Some applications, notably Sitecore, generate very large query strings that can exceed the maximum HTTP header size of a GET request, resulting in HTTP 413 errors.

If your queries run out of header space, you’ll be interested in these possible strategies:

• Adjust HTTP header size. The header size can be increased as needed on Azure single-node deployments; but only up to a limit of 32 KB on Azure clusters. This means that large header sizes on test (single-node) deployments often cannot be transferred to production clusters on Azure.
• Use POST queries instead of GET queries. This moves the query string out of the HTTP header into the body of the request.
• Adjust the query complexity to reduce the size of the query string. See Solr query error – URI Too Long for suggestions on how to pare down the Sitecore queries to meet this limitation. Ultimately, you’ll need to discuss this with Sitecore support.

Using POST Queries

If you encounter this 413 heading error in a non-Sitecore context, you can issue POST query requests using the following Linux curl or Windows PowerShell request formats.

Linux:

curl -d "q=*:*&rows=1" https://ss123456-dkwl9slx-ca-central-1-aws.searchstax.com/solr/filmcollection/select

Note that the -d (data) switch automatically casts the request as a POST message.

PowerShell:

$params= @{
     q='*:*'
     rows=10
     wt='json'
     indent='true'
     fl='id,movie_title,title_year'
          }

$queryresults = Invoke-RestMethod -Method Post -body $params `
                -ContentType 'application/x-www-form-urlencoded' `
                -uri "https://ss123456-dkwl9slx-ca-central-1-aws.searchstax.com/solr/filmcollection/select"

The post POST vs. GET Requests appeared first on SearchStax Docs.

This occurs when Sitecore has been configured to use only one schema for all collections, and the user tries to populate it from all of the collections at the same time. This creates a race condition where many of the updates time out and are not included in the schema.

Using the Managed Search Connector for Sitecore obviates this situation by creating a separate schema for each Sitecore collection. The critical setting is isUniqueConfigs : “true” in the configs.yml file. If you change that value to “false”, you are inviting the race-condition bug.

The easy work-around is to repopulate the schema by adding one collection at a time from the Sitecore interface.

The post Why does Sitecore fail to populate schemas? appeared first on SearchStax Docs.