Sitecore Lucene: content delivery server index not updating on publish

Question

I created a custom search page using the default sitecore_web_index and everything seemed to work until I migrated to my test environment that has separate content management and content delivery servers. The index on the CD server is not getting updated on publish (the CM server does), if I rebuild the index from the control panel, I see updates. So I believe the index and the search page are working correctly.

The index is using the onPublishEndAsync strategy. The Sitecore Search and Index Guide (http://sdn.sitecore.net/upload/sitecore7/70/sitecore_search_and_indexing_guide_sc70-usletter.pdf) section 4.4.2 states:

This strategy does exactly what the name implies. During the initialization, it subscribes to the OnPublishEnd event and triggers an incremental index rebuild. With separate CM and CD servers, this event will be triggered via the EventQueue object, meaning that the EventQueue object needs to be enabled for this strategy to work in such environment.

My web.config has <setting name="EnableEventQueues" value="true"/>

Also from the Search and Index Guide:

Processing
The strategy will use the EventQueue object from the database it was initialized with: <param desc="database">web</param>
This means that there are multiple criteria towards successful execution for this strategy:

• This database must be specified in the <databases /> section of the configuration file.
• The EnableEventQueues setting must be set to true.
• The EventQueue table within the preconfigured database should have entries dated later than index's last update timestamp.

I'm not sure of the <param desc="database">web</param> setting, because the publishing target (and database ID) for the CD server is pub1. I tried changing web to pub1, but then neither servers' index was updated on a publish (so it's changed back to web).

The system was recently upgraded from Sitecore 6.5 to 7.2, so there are a couple indexes using Sitecore.Search API and these indexes are updated on publish.

Is the database param on the EventQueue wrong considering the multiple publishing targets? Is there something else I'm missing, or perhaps a working example of a CM -> CD environment I could compare to?

TIA

EDIT: If I wouldn't have had a co-worker sitting next to me both Friday and today who can confirm, I would think I'm going crazy. But now, the CD server is getting updates to the index, but the CM server is not getting updates. What would make the CM server not get updates now?

Answer 1

I ran into this same issue last night and have a more predictable resolution than creating a new IIS site:

The resolve was to set a distinct InstanceName in ScalabilitySettings.config for each CD server, instead of relying on the auto-generated name.

Setting this value immediately resolved the issue and restored the index update functionality upon Publish End Remote events.

Note: If you already have an InstanceName defined in your config, then you need to change it for this to work. I just increment the InstanceName with the date to force the change.

This is effectively fixing the same issue in the same way as the original poster did by changing to a new IIS site, as the OP's fix would have modified the auto-generated Instance Name based on the new IIS site name.

I believe the core problem with the OP (and also in my instance) is related to the EventQueue databases going out of sync with the CD instances and none of the servers being able to determine that an event has been generated / what content needs to update in the index. By changing the Instance Name (using either method) the servers appear to be new instances and start from scratch with their EventQueue tracking.

Every time I've seen issues like this in the past it's been related to major manipulations of Sitecore databases. Such as restorations, backup/restore to a new DB name, or rollbacks of databases due to deployment problems. I believe something in the above operations causes the EventQueues to get out of sync and the servers stop responding to the expected events.