This project is read-only.

Web Farm and indexing

Topics: Troubleshooting
Jul 1, 2011 at 8:22 AM

We're having issues with search indexes on a 4 node web farm, anyone got any ideas what is going on?

Server Error in '/' Application.

Object reference not set to an instance of an object.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error: 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace: 


[NullReferenceException: Object reference not set to an instance of an object.]

    Orchard.Indexing.Services.IndexingTaskExecutor.BatchIndex(String indexName, String settingsFilename, IndexSettings indexSettings) +5382

    Orchard.Indexing.Services.IndexingTaskExecutor.UpdateIndexBatch(String indexName) +1367

    Orchard.Indexing.Services.UpdateIndexScheduler.UpdateIndex(String indexName) +119


Jul 1, 2011 at 6:55 PM

This is a known bug in Orchard 1.1. You can apply the patch to your servers, if bug #17752, and the changeset is 78c726c1cd8d.

This is also solved by default in Orchard 1.2

Sep 22, 2011 at 3:04 AM

Hi there,


In a web farm, how is the search index configured. Is there one centralized index across all nodes  (or) does each node contain its own index, if so how are indexes synchronized?



Sep 22, 2011 at 4:41 AM

Each node has its index. They are synchronized by indexing the same content database. Change notifications are properly propagated.

Sep 22, 2011 at 4:51 AM

Indexes are duplicated across each node. Each node is responsible for keeping its index up to date. This is done using a background task running on each of them, and using a common Index Tasks table. Each node also retains which task it is synchronized to. At maximum it can take 1 minute from a change in db to index update, so discrepancies are trivial issues here. You can yet implement your own Indexing module to handle a central location for the index if necessary. This has been discussed already today for Azure, which works the same as explained here.

Sep 23, 2011 at 3:03 AM

Thanks Bertrand/Sebastien.


We are looking to setup Orchard in 2 datacenters (1 master for admin site to make cms admin changes and both datacenters which will be used as live/live for the public website).

For now i don't want to go for a centralized index (as the indexes are going to be really small).

Can the following work?

  • Two datacenters A and B.
  • A is the master CMS admin site, Databases changes in datacenter A replicate to datacenter B.
  • As per your explanation above, it looks like the search index can run in each web node and will poll the respective datacenter Db/table for indexing tasks. I can see this working perfectly in Datacenter A.
  • Considering Datacenter B would be getting a replicated copy of Datacenter's A data, do you see any issues with Datacenter B webnode search indexes keeping up to date?


Sep 23, 2011 at 5:19 AM

You might have to exclude some tables from the replication then. Sébastien?

Sep 24, 2011 at 2:01 AM

Thanks Bertrand.



Would you be able to hint us on what tables we should exclude for setting up replication of Orchard DB across 2 datacenters but still have indexing enabled?



Sep 24, 2011 at 4:03 AM

Nope, no table would have to be excluded, the current state of each node is saved in App_Data\Sites\NAME\indexing.xml

Everything should work as is.

Sep 24, 2011 at 4:04 AM
Thanks Sebastien.


From: sebastienros <>
Reply-To: <>
Date: 23 Sep 2011 20:04:09 -0700
To: Venkat Krishnamoorthy <>
Subject: Re: Web Farm and indexing [orchard:263515]

From: sebastienros

Nope, no table would have to be excluded, the current state of each node is saved in App_Data\Sites\NAME\indexing.xml

Everything should work as is.

May 2, 2013 at 3:53 PM
I am having a similar issue with a couple of sites that range in version from 1.3-1.5 and are in a similar environment. I have two production servers that are load balanced and replicate files between one another. Both servers/Orchard sites tie back to the same SQL cluster so they are using the same DB. The replication process will slide the newest version of any file (except *.txt files) to the other server immediately. I'm thinking that the indexing tasks for a site is attempting to update the index files at the same time it's twin is doing the same on the other server ... all while the replication is then trying to throw the index files back and forth. What ends up happening is the search on the front side produces zero results. No other signs of a problem occur. To bring the index back I need to tell one site to rebuild the index (I sometimes need to stop the sites twin on the other server so the replication doesn't kick in going in the wrong direction).

My Question: Is the solution to simply tell the replication process to ignore the 'Index' directory for the site or is there a more elegant/smarter way to deal with this?
May 2, 2013 at 6:12 PM
The only solutions:
Do not replicate the App_data folder at all