7

I'm running Sitecore 8.2 Update 4 with Solr 5.5 (running inside of a Linux Docker container). I'm trying to get Sitecore to tell Solr to populate the indexes. Here's my setup:

  1. Downloaded the Solr 5.5 docker image.
  2. Copied a valid Solr Schema file (taken from our test environment) to the appropriate configs folder.
  3. Changed the solrconfig.xml file to use ClassicIndexSchemaFactory.
  4. Populated my cors using a powershell script which has proven to work fine in other environments.
  5. Using ShowConfig.aspx I was able to verify that Sitecore is pointing to my local instance of Solr.
  6. Verified that Solr is running and accessible from the address that Sitecore is looking at.
  7. Verified that Sitecore is running in SOLR mode and not Lucene mode.

Now, when I try to run the re-indexing process, I get this screen:

Indexing Manager Empty

I've checked the Sitecore Logs, and all it says is this:

12116 16:41:25 INFO  AUDIT (sitecore\admin): Rebuild indexes from Indexing Manager: sitecore_master_index
ManagedPoolThread #7 16:41:25 INFO  Job started: Index_Update_IndexName=sitecore_master_index
ManagedPoolThread #7 16:41:25 INFO  Job ended: Index_Update_IndexName=sitecore_master_index (units processed: )

And in SOLR, I'm seeing no logs whatsoever. No SOLR Errors Logged

I've also verified that I don't have any documents in my master database, which has over 70,000 items in it. No documents

I'm not sure where I should start looking for errors.

Update: Thanks to the comments, I'm able to see the following errors in my crawling.log file. I'm not sure what they mean because my SOLR instance is up and running and available, but at least it's something to go on. Here's the log:

8316 10:15:02 WARN Failed to initialize 'sitecore_analytics_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_core_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_master_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_web_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_marketing_asset_index_master' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_marketing_asset_index_web' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_marketingdefinitions_master' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_marketingdefinitions_web' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_testing_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_suggested_test_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_fxm_master_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_fxm_web_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'sitecore_list_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'social_messages_master' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'social_messages_web' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

8316 10:15:02 WARN Failed to initialize 'mediaframework_ooyala_index' index. Registering the index for re-initialization once connection to SOLR becomes available ...

8316 10:15:02 WARN DONE

18
  • Do you have errors in your "Crawling" log? Commented Dec 9, 2017 at 1:11
  • What url do you have configured? Commented Dec 9, 2017 at 1:58
  • Firewall? Turn logging up to Full in Sitecore config Commented Dec 9, 2017 at 3:09
  • Did you clear your target environment of any leftover *Lucene.config files? Leaving them around can cause all sorts of upset, even if you rmain config setup now points to SOLR.
    – Mark Cassidy
    Commented Dec 9, 2017 at 9:25
  • Does your SOLR log show anything? Commented Dec 9, 2017 at 16:22

3 Answers 3

3

Sounds very odd, if you were using Solr Cloud then might have been Zookeeper was down when SOLR started up. Or you might have missed out creating the SOLR aliases. Don't see a mention of SolrCloud or Zookeeper though.

Other than checking collections and configs match up.

To see what is going on, install Fiddler, change your sitecore app pool to run as your Windows user (processes running under same user go through Fiddler by default), change the solr connection string to localhost.:8983 (extra dot makes it go through fiddler proxy) Restart sitecore, see what requests are being attempted to Solr and what response is returned.

Hopefully that helps.

1

Recently encountered the same Registering the index for re-initialization once connection to SOLR becomes available with an additional Error handling 'status' action in the crawling log. After double checking all our configs, we found that we had inadvertently used a ServiceBaseAddress from another integration environment (old variable from a cloned VSTS release) and the two sites were fighting for contention (I can only assume constant rebuilds and updates). Simply cloning the resource to a new VM and updating the address resolved the issue. May not be the exact issue in your case but hope it helps someone else in the future.

0

In Sitecore.XA.Foundation.Search.Solr.config, for each index core,

<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
  <patch:attribute name="type">Sitecore.XA.Foundation.Search.Providers.Solr.SolrSearchIndex, Sitecore.XA.Foundation.Search.Providers.Solr</patch:attribute>
  <param desc="core">testytesty_sitecore_web_index</param>
  <locations hint="list:AddCrawler">
   <crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
    <patch:attribute name="type">Sitecore.XA.Foundation.VersionSpecific.Search.SitecoreItemCrawler, Sitecore.XA.Foundation.VersionSpecific</patch:attribute>
   </crawler>
  </locations>

This line:

<param desc="core">testytesty_sitecore_web_index</param>

Points to the index on the Solr server.

Whereas this line:

<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">

I'm guessing points to the local reference.

Changing the first should help.

There may still be bugs after this step, but hopefully different ones

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.