- Sitecore Indexes not Loading
- Inactivity Timeout During Rebuild
- Problem Loading the Ninject Assembly
- Internal Server Error When Querying the REST Service
- Editing the Properties of a Coveo Search MVC Component Freezes the Page Editor in IE11
- Error or Document Not Found Page After Rebuilding the Indexes
- Problem Registering Search Page Events in Sitecore Analytics Database
- High Memory Usage While Rebuilding Indexes
- Root Element of a Crawler for a Coveo Index is Invalid
- HTML Version of Indexed Items Are Showing an Error Page
- NullReferenceException on Tracking.Current When Executing a Request for a Quick View
- Getting log4net Errors When Attempting to Browse Sitecore Pages
- Inserting an Example Search Page Results in No Renderings
- An Index Should Be Configured for Database Web Error Is Preventing the REST Service From Loading
- Cannot insert the value NULL into column ID, table INSTANCE_HOSTNAME_Core.dbo.Properties column does not allow nulls. INSERT fails.
- ERROR Error in FileWatcher Internal Buffer Overflow While Installing Coveo for Sitecore
- ERROR Exception while handling event Sitecore.ContentSearch.Events.IndexingFinishedEvent, Index MY_INDEX was not found
- Failed to Reactivate the Organization Message in Command Center
- Handler CoveoSearchEndpoint has a bad module ManagedPipelineHandler in its module list
- Items in Different Languages Are Not Automatically Indexed or Updated When Language Fallback Is Enabled
- Missing Valid xDB License
- Opening the Experience Explorer Sets the Static Context to 'Master'
- Prebinding Isn't Applied to Elements Within a Searchbox Container
- Publishing Multi-Language Sitecore Items Leads to a Large Amount of Files Being Indexed
- Sitecore 8.2 With WFFM Refuses to Start After Installing Coveo for Sitecore
- Sitecore.ContentSearch.SitecoreItemCrawler.IsAncestorOf(Item item) error
- Solr - Error When Initializing Coveo When Side-by-Side With Solr Is Enabled
- The RouteData must contain an item named 'controller' Error With SXA
- Sitecore SXA Throws Errors When Upgrading From Coveo for Sitecore 4.1 to Coveo for Sitecore 5
- Unexpected Token When Editing Page With SXA Components in Experience Editor
- Select the Associated Content Dialog Not Popping Up in SXA 1.8
- Could Not Find Property skipFirstTimeSetupCheck Error
- Send Analytics to Sitecore Component Not Working in Sitecore 9
- Two Instances of the Same Search Page Component Have Been Added on a Page but Only One is Initialized
- Dynamic Placeholders Not Displaying Allowed Renderings in SXA
- Failed to Configure the Organization Error When Trying to Switch Organization
- SXA Coveo Facet Value Suggestions Rendering Item Overwriting Hive Item at Installation
- Issues When the Core Database Is Disabled on Content Delivery Servers
- Content Database 'master' Not Found on a Content Delivery Server
- Sitecore 9 Content Delivery Instance Crashes at Index Initialization
- Coveo Analytics Events Are Not Logged in Sitecore 9.1 Analytics
- Compilation Error in Diagnostic Page in Sitecore 7.5 and 8.0
- Ajax Error 500 When Using Special Characters in a Query
- Dynamic Facet Range Not Showing When Returning From a No Result Query
- Master Index Old Item Versions Not Getting Deleted in Sitecore 9.1+
- Unhandled Exception After Installing Coveo for Sitecore on Sitecore 8.0 or 8.1 Instance
- The coveoProcessParsedRestResponse Pipeline Is Not Being Executed
- Unhandled Exception in Content Editor Prior to Coveo for Sitecore Activation
- Could Not Find Configuration Node Error on CD
- Components Aren't Rendering Or Analytics HTTP Requests Are Failing Intermittently
Inactivity Timeout During Rebuild
Inactivity timeout is part of all rebuild processes for any system. This situation is different than when the system shuts down and restarts itself right after you installed new software or enabled new functions. In these cases, it always warns you before OR suggests that you delay the restart – although delaying isn’t recommended.
Coveo for Sitecore and the platform are meant to synchronize automatically, except beyond a certain number of new documents, where rebuilding is necessary. A rebuild updates indexes in Sitecore by pushing all new documents from Coveo for Sitecore into the Sitecore source in the platform.
To trigger the rebuild process, you go through the following steps (see Analyze the Rebuild Process for more detailed steps):
You send a rebuild request. Permissions are then sent to Coveo Cloud.
The system detects the number of documents to be pushed into the platform and then indexed.
When pushing and indexing are completed, the rebuild proceeds to remove all old items from the indexes. However, it may happen that out of 567 new documents, only 489 are pushed into the indexes.
Different steps of the rebuilt process have different inactivity timeouts:
The validation step times out after 1 hour of inactivity
The step responsible for removing old items times out after 5 minutes of inactivity.
After running for one hour without activity, the rebuild will interrupt itself. Based on the difference between numbers of committed and expected items, you will understand that the Coveo indexes aren’t fully updated.
The most visible sign of an inactivity timeout issue is a characterizing error message in the Sitecore logs. When the rebuild is over, you should see that the last report on the number of committed documents didn’t reach the expected total.
The following gives an example of a situation where only 21,325 documents were verified searchable (committed) out of a total of 23,052 documents:
ManagedPoolThread #0 10:35:02 INFO [...] [Rebuilding source "Coveo_web_index - <FARM_NAME>"] Committed documents: 21325 / 23052 [...] ManagedPoolThread #18 11:35:07 ERROR [ Coveo.SearchProvider.ProviderIndexBase PerformRebuild] [Rebuilding source "Coveo_master_index - <FARM_NAME>"] An error occurred while rebuilding index "Coveo_master_index". Exception: Coveo.Framework.Exceptions.CoveoSearchProviderException Message: Inactivity timeout expired. Not all documents were committed in the allotted time (01:00:00). Aborting the rebuild task. Source: Coveo.AbstractLayer
When a system doesn’t detect activity for a certain number of minutes, it automatically shuts down. This can also happen while installing software and not completing the required steps in time.
They’re the most common cause of inactivity timeout. The platform usually bugs when you send an invalid document to the index. It might be a PDF that doesn’t have an assigned user or owner, is locked, fails to open, etc. They’re easy to diagnose , since they display error codes (Error_code), like CORRUPTED_DOCUMENT. The index basically tries to protect itself and the platform from corrupted, potentially dangerous data (a document carrying viruses, for example).
Some permissions might not send, or some documents might hold bad permissions. When a document is pushed into the Sitecore Source, it needs to hold the matching permission. Permissions identified on the item as X but in the Coveo index as Y, although they virtually are the same, don’t have matching names, and therefore won’t be recognized by the Sitecore source. The document will be left with an unknown permission, which prevents its indexing after the push.
If you send an item into the Sitecore Source, but the users/permissions don’t follow, you will run into inactivity timeout because the rebuild will have failed. The rebuild process will have failed because there will be one or more documents without a known user. The next section links you to page that explains you how to solve that problem.
Number of Items and Reset Issues
Uploading many items in Sitecore can also slow down the rebuild process, as there’s a maximum number of items and/or security identities that may be pushed each hour. If you want to push many items into the Sitecore source, the rebuild will simply take longer to conclude. However, if you’re using an older version of Coveo for Sitecore, you might run into an inactivity timeout. Improvements have been made to more recent versions, and you’re encouraged to upgrade to the most recent one.
However, cases of interruption related to the number of items are very rare. What’s most likely to cause an interruption is the timer refreshing if the upload process detects change in the number of documents.
|Time||Number of documents processed||Timer state|
|11h10||10/100||5 minutes, reset at 0|
|11h15||10/100||10 minutes, no change|
|12h05||10/100||55 minutes, no change|
Or, if there's change:
(which means that next inactivity timeout will occur at 13h10, unless there's change)
|1 hour, inactivity, reset at 0|
The step Waiting for documents to be searchable failed because although documents were pushed correctly, the query couldn’t find them. The reason to this failure is usually that the user executing the query doesn’t have the right to see some indexed documents. Invalid permissions trigger security issues in the rebuilt process, which might cause it to fail.
If written on an item that a user is allowed to view it, but doesn’t actually own this permission, the rebuild will interrupt itself before indexing the documents.
To solve the problem of non-completed indexing, restart the rebuild. If the numbers of committed and expected documents even out, you will want to test the rebuild by looking up random items in the Coveo indexes. If you search for an old document, it shouldn’t exist in the indexes anymore, while an item pulled from Coveo for Sitecore to the platform should be indexed. If this doesn’t work, identify the possible cause and apply one of the following solutions.
Look up which documents are broken and either remove them from the platform, or fix their issue.
Most problems related to users, groups and permissions associated to pushed items can be validated directly in the “Content Security” tab in the Cloud Administration Console.
Number of Items and Reset Issues
To avoid problems with permissions related to a large number of documents, make sure you’re using the Push API batch process, which compresses items before processing them.
To understand the problem related to a failed query, see if indexed dates on indexed documents were updated during the rebuild. If yes, the rebuild is simply still running.