2

I have a working custom index configured, it includes some custom fields and has specifically included fields and templates to keep it light. It uses the default SitecoreItemCrawler. I'm on 10.1 deployed on Azure.

I just want to run an update on a specific document in my index, to force some computed fields to be recomputed and persisted in the Solr index.

I'm struggling to get IndexCustodian to perform the update, here is relevant code:

        using (var solr = ContentSearchManager.GetIndex("my_site_search"))
        {
            // just for example, this comes from elsewhere
            string exItemUri = "sitecore://web/{d1adabf3-393e-4d59-b9e3-a3104253b879}?lang=en&ver=1";
            var ctx = solr.CreateSearchContext(Sitecore.ContentSearch.Security.SearchSecurityOptions.DisableSecurityCheck);
            using (new SecurityDisabler())
            {
                Log.Info($"Context User: {Sitecore.Context.User.Name}", "SU");
                var indexableUniqueIds = new[] { new SitecoreItemUniqueId(exItemUri) };
                
                    var db = Factory.GetDatabase("web");
                    var it = db.GetItem(new DataUri(exItemUri));
                    var tempItem = (SitecoreIndexableItem)it;
                    
                    // ** THIS DOES NOT WORK #1
                    // solr.Refresh(tempItem); This also doesnt work - noted comment that this should not be done, IndexCustodian should be used
                    var job = IndexCustodian.Refresh(solr, tempItem);
                    //job.Start(); // doesn't make any difference - job is started anyway by IndexCustodian(?)
                    job.Wait();

                    Log.Info("Ran Refresh: indexUniqueIds: " + indexableUniqueIds[0].ToString(), "SU");
                

                    // ** THIS WORKS, BUT I'M NOT USING THE INDEXCUSTODIAN #2
                    using (var upctx = solr.CreateUpdateContext())
                    {
                        solr.Operations.Update(tempItem, upctx, solr.Configuration);
                        upctx.Commit();
                    }
                Log.Info("Ran Update indexUniqueIds: " + indexableUniqueIds[0].ToString(), "SU");
            }
        }

I've tried various methods on IndexCustodian (.Update, .Refresh, .ForcedIncrementalUpdate etc), but all have the same effect - I see the job going into the jobs queue, it gets processed, however does nothing to my index - it also states 0 items updated. I'm examining index with the Solr query tool.

I've run out of things to try - I'm not sure if approach #2 is correct as I believe we are supposed to use the IndexCustodian.

Any help greatly appreciated!

2 Answers 2

1

Got to the bottom of it - I noticed that my code #1 did work the first time after an app pool recycle. I then noticed that my crawler stopped immediately after the first run in crawling logs:

WARN  [Index=my_site_search] Crawling Stopped

Subsequent attempts using IndexCustodian would fail immediately (with no error).

Decompiling Sitecore.ContentSearch.ISearchIndex then pointed me at the dispose method of Sitecore.ContentSearch.AbstractSearchIndex.

Fix in my code above was to remove the using clause around:

var solr = ContentSearchManager.GetIndex("my_site_search")

Dispose doesn't get called, crawler continues, and further calls to #1 work as expected on all methods - (.Update, .Refresh, .ForcedIncrementalUpdate etc)

Just answering in case it helps someone else in future.

Thanks to Balaji's answer here https://sitecore.stackexchange.com/a/4674/4299 for pointing me to the underlying problem.

0

You can also try something like this:

void RefreshIndex(Item item, string indexName)
{
    using (var searchContext = ContentSearchManager.GetIndex(indexName).CreateSearchContext())
    {
        searchContext.Index.Refresh(new SitecoreIndexableItem(item), IndexingOptions.ForcedIndexing);
    }
}
1
  • Thanks for the reply, but this doesn't use the IndexCustodian, which is highly recommended according to doc.sitecore.com/xp/en/developers/101/… I'd be concerned about deploying that to production.
    – geedubb
    Commented Sep 13, 2022 at 15:24

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.