Kamruz Jaman - Solution Architect
27 Feb 2021
Just a couple of days ago, Sitecore XP 10.1 was released with even greater container support. If you want to take this new version for a quick spin or you are new to Docker then check out my previous post where I introduce you to the Konabos Example Docker repository, which has now been updated to work with Sitecore 10.1 🥳
There have been some chaages to the containers and the related compose file, specifically around the way that the Solr containers are now spun up. Unfortunately in the Docker Hub, the only type of image available for Apache Solr is Linux based and running mixed container types (both Windows and Linux based) at the same time is still an experimental feature. So Sitecore decided to help us out and create a Windows based Solr container, but whereas in Sitecore 10 there was only a single Solr container, in Sitecore 10.1 there is an additional solr-init container:
solr: isolation: ${ISOLATION} image: ${SITECORE_DOCKER_REGISTRY}nonproduction/solr:8.4.0-${SITECORE_VERSION} ports: - "8984:8983" volumes: - type: bind source: .\solr-data target: c:\data environment: SOLR_MODE: solrcloud # Some modules (like SXA) also require additions to the Solr image. solr-init: isolation: ${ISOLATION} image: ${SITECORE_DOCKER_REGISTRY}sitecore-xp0-solr-init:${SITECORE_VERSION} environment: SITECORE_SOLR_CONNECTION_STRING: http://solr:8983/solr SOLR_CORE_PREFIX_NAME: ${SOLR_CORE_PREFIX_NAME} depends_on: solr: condition: service_healthy
The intention here is to have as close to stock solr image without any Sitecore additions (just that it is Windows based) and then the solr-init can bootstrap in the Sitecore specific cores. And this works fine, and you can even see that for SXA based images we can copy in the configuration for the SXA cores to be created.
However, when you go to build or rebuild the indexes you will get the following error:
Job started: Index_Update_IndexName=sitecore_master_index|#Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> SolrNet.Exceptions.SolrConnectionException: <?xml version="1.0" encoding="UTF-8"?> <response> <lst name="responseHeader"> <int name="rf">1</int> <int name="status">400</int> <int name="QTime">4</int> </lst> <lst name="error"> <lst name="metadata"> <str name="error-class">org.apache.solr.common.SolrException</str> <str name="root-error-class">org.apache.solr.common.SolrException</str> </lst> <str name="msg">undefined field _indexname</str> <int name="code">400</int> </lst> </response> ---> System.Net.WebException: The remote server returned an error: (400) Bad Request. at System.Net.HttpWebRequest.GetResponse() at HttpWebAdapters.Adapters.HttpWebRequestAdapter.GetResponse() at SolrNet.Impl.SolrConnection.GetResponse(IHttpWebRequest request) at SolrNet.Impl.SolrConnection.PostStream(String relativeUrl, String contentType, Stream content, IEnumerable`1 parameters) --- End of inner exception stack trace --- at SolrNet.Impl.SolrConnection.PostStream(String relativeUrl, String contentType, Stream content, IEnumerable`1 parameters) at SolrNet.Impl.SolrConnection.Post(String relativeUrl, String s) at SolrNet.Impl.LowLevelSolrServer.SendAndParseHeader(ISolrCommand cmd) at Sitecore.ContentSearch.SolrProvider.SolrSearchIndex.PerformReset(ISolrOperations`1 operations, String indexName) at Sitecore.ContentSearch.SolrProvider.SolrSearchIndex.PerformRebuild(Boolean resetIndex, Boolean optimizeOnComplete, IndexingOptions indexingOptions, CancellationToken cancellationToken) at Sitecore.ContentSearch.SolrProvider.SolrSearchIndex.Rebuild(Boolean resetIndex, Boolean optimizeOnComplete) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Sitecore.Reflection.ReflectionUtil.InvokeMethod(MethodInfo method, Object[] parameters, Object obj) at Sitecore.Jobs.JobRunner.RunMethod(JobArgs args) at (Object , Object ) at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain, Boolean failIfNotExists) at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) at Sitecore.Jobs.DefaultJob.DoExecute() at Sitecore.Abstractions.BaseJob.ThreadEntry(Object state)
The solution to fix this error is quite simple. Seems like due to the changes to the solr container format the schema now needs to be populated the first time after the instance is first spun up.
Go to the Control Panel, select Populate Managed Solr Schema, select all the indexes and hit Populate and then wait...
After you get the success message you can go back and rebuild the indexes successfully.
Wooohoooo 🎉 Hope this helps you!
EDIT
Kamruz is a 11-time Sitecore MVP who has worked with the Sitecore platform for more than a decade and has over 20 years of development and architecture experience using the Microsoft technology stack. Kamruz is heavily involved in the Sitecore Community and has spoken at various User Groups and Conferences. As one of the managing partners of Konabos Inc, Kamruz will work closely with clients to ensure projects are successfully delivered to a high standard.
Share on social media